From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | David Fetter <david(at)fetter(dot)org> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Committers <pgsql-committers(at)postgresql(dot)org> |
Subject: | Re: pgsql: Properly handle empty arrays returned from plperl functions. |
Date: | 2011-08-17 21:17:02 |
Message-ID: | 4E4C2FCE.3080803@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
On 08/17/2011 04:59 PM, David Fetter wrote:
> On Wed, Aug 17, 2011 at 01:29:01PM -0400, Andrew Dunstan wrote:
>>
>> On 08/17/2011 12:53 PM, Alvaro Herrera wrote:
>>> Excerpts from Andrew Dunstan's message of mié ago 17 12:41:47 -0400 2011:
>>>> Wow, sorry for the noise. I guess I'll be more careful about reusing a
>>>> commit-message file.
>>> Happened to me once too (back when we used CVS). It seems the filter to
>>> remove unwanted lines is not applied when the file is specified in the
>>> command line which seems a bit silly to me.
>> Right, certainly a violation of POLA.
> It is indeed. What script or scripts handle this?
>
>
It's not a script. "git commit -F filename" is the culprit. It seems if
you intend to reuse the message file that git carefully saves for you,
you need to trim the comment lines. What I did was in the master branch,
"git commit -a" and then in the 9.1 branch "git commit -a -F
/path/to/master/.git/COMMIT_EDITMSG" to reuse the commit message, not
realizing it would not trim the comment lines if I use -F, unlike when
it puts me into the editor.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-08-17 21:33:10 | pgsql: Fix two issues in plpython's handling of composite results. |
Previous Message | David Fetter | 2011-08-17 20:59:39 | Re: pgsql: Properly handle empty arrays returned from plperl functions. |