RE: Is this a bug?

Hi,

I wrote a commit message beginning with a hash (#) character, like this: 'git commit -m "#ifdef ...." '

Everything went okay when committing, but then I tried 'git commit -amend' and without editing the commit message I was told I had an empty commit message.

Is this a problem with my text editor (vim 7.2) or git itself? (git version 1.7.2.2 under RedHat 5.8) Or something I'm not supposed to do ;-) ?

Thanks!

David Wade
Analyst, Seismic Imaging Development
ITC SUB RES
Statoil ASA

Mobile: +47 97572157
Email: dawad@statoil.com

Visitor address: Vassbotnen 23, Forus, Norway
Incorporation number: NO 923 609 016 MVA
www.statoil.com
Please consider the environment before printing this e-mail.


-------------------------------------------------------------------
The information contained in this message may be CONFIDENTIAL and is
intended for the addressee only. Any unauthorised use, dissemination of the
information or copying of this message is prohibited. If you are not the
addressee, please notify the sender immediately by return e-mail and delete
this message.
Thank you

On 02/19/2013 10:32 AM, David Wade wrote:

Hi,

I wrote a commit message beginning with a hash (#) character, like
this: 'git commit -m "#ifdef ...." '

Everything went okay when committing, but then I tried 'git commit
-amend' and without editing the commit message I was told I had an
empty commit message.

Is this a problem with my text editor (vim 7.2) or git itself? (git
version 1.7.2.2 under RedHat 5.8) Or something I'm not supposed to do
;-) ?

Lines starting with a hash sign are considered comments by git commit.
If you fire it up without '-m' you'll see that git puts all its own
notes about the commit in commented-out lines.

While empty commit messages aren't really unacceptable by git's model,
they're considered "almost certainly user errors". I expect the -m
flag being present when running 'git commit' causes the check for empty
message to be skipped, which isn't the case when amending the commit.


Btw, when I write messages probably similar to the one you just did, I
tend to write:
  Use compat-layer __builtin_clz() #ifndef __GNUC__
precisely to avoid this issue. It also puts the imperative first,
which I find makes for smoother reading. Putting the condition first
screams for a comma and a slight stagger in reading flow, like so:
  Unless built with gcc, use compat-layer __builtin_clz()

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

On Tue, Feb 19, 2013 at 10:32 AM, David Wade [off-list ref] wrote:

Hi,

I wrote a commit message beginning with a hash (#) character, like this: 'git commit -m "#ifdef ...." '

Everything went okay when committing, but then I tried 'git commit -amend' and without editing the commit message I was told I had an empty commit message.

Is this a problem with my text editor (vim 7.2) or git itself? (git version 1.7.2.2 under RedHat 5.8) Or something I'm not supposed to do ;-) ?

The problem is that when doing interactive editing of messages (like
'git commit --amend' does), git considers '#' as a comment-character.
You can disable this by using the --cleanup=verbatim switch (or some
other suiting cleanup-setting, see 'git help commit').

On Tue, Feb 19, 2013 at 4:47 PM, Erik Faye-Lund [off-list ref] wrote:

On Tue, Feb 19, 2013 at 10:32 AM, David Wade [off-list ref] wrote:

quoted

Hi,

I wrote a commit message beginning with a hash (#) character, like this: 'git commit -m "#ifdef ...." '

Everything went okay when committing, but then I tried 'git commit -amend' and without editing the commit message I was told I had an empty commit message.

Is this a problem with my text editor (vim 7.2) or git itself? (git version 1.7.2.2 under RedHat 5.8) Or something I'm not supposed to do ;-) ?

The problem is that when doing interactive editing of messages (like
'git commit --amend' does), git considers '#' as a comment-character.
You can disable this by using the --cleanup=verbatim switch (or some
other suiting cleanup-setting, see 'git help commit').

Nobody is always conscious about the leading # in commit message to do
that. I once edited a commit message and the auto-wrap feature put '#'
at the beginning of the line. I saved and went on without noticing one
line was lost until much later :( Perhaps we should change the comment
signature a bit to reduce accidents, like only recognize '#' lines as
comments after a special line like

# this is not a comment
### START OF COMMENT ###
# this is a comment
-- 
Duy

On Tue, Feb 19, 2013 at 6:02 AM, Duy Nguyen [off-list ref] wrote:

On Tue, Feb 19, 2013 at 4:47 PM, Erik Faye-Lund [off-list ref] wrote:

quoted

On Tue, Feb 19, 2013 at 10:32 AM, David Wade [off-list ref] wrote:

quoted

Hi,

I wrote a commit message beginning with a hash (#) character, like this: 'git commit -m "#ifdef ...." '

Everything went okay when committing, but then I tried 'git commit -amend' and without editing the commit message I was told I had an empty commit message.

Is this a problem with my text editor (vim 7.2) or git itself? (git version 1.7.2.2 under RedHat 5.8) Or something I'm not supposed to do ;-) ?

The problem is that when doing interactive editing of messages (like
'git commit --amend' does), git considers '#' as a comment-character.
You can disable this by using the --cleanup=verbatim switch (or some
other suiting cleanup-setting, see 'git help commit').

Nobody is always conscious about the leading # in commit message to do
that. I once edited a commit message and the auto-wrap feature put '#'
at the beginning of the line. I saved and went on without noticing one
line was lost until much later :( Perhaps we should change the comment
signature a bit to reduce accidents, like only recognize '#' lines as
comments after a special line like

# this is not a comment
### START OF COMMENT ###
# this is a comment

Or maybe --amend should imply --cleanup=whitespace.
--
Phil