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:

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()

On Tue, Feb 19, 2013 at 10:32 AM, David Wade <DAWAD@statoil.com> wrote:

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 <kusmabite@gmail.com> wrote:

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

On Tue, Feb 19, 2013 at 6:02 AM, Duy Nguyen <pclouds@gmail.com> wrote:

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

Phil Hord <phil.hord@gmail.com> writes:

I am fairly negative on that.

Such a hidden linkage, even if it is documented, is just one more thing people need to learn.

It _might_ be interesting (note: I did not say "worthwhile" here) to think what happens if we scanned the message (either coming from the commit being amended, -F file option, or -m message option), picked a punctuation character that does not appear at the beginning of the lines in it, and automatically adjusted core.commentchar if '#' appears at the beginning of one of the lines, though.