2

Using Git 2.11.1.windows.1, SourceTree 1.10.20.1.

I though by default git ignores lines starting with # in commit message. However, using SourceTree, I tried a multilines commit message:

Testing multilines commit message
# Line 2
# Line 3

Surprisingly the all the 3 lines are recorded as commit message (seen by git log). Maybe git nned to be configured with a default comment character, so I set

git config --global core.commentChar "#"

Then undo the commit by git reset --soft HEAD^ and recommit with the same 3 lines message (using SourceTree, don't know how to make multilines commit msg at command line). The lines beginning with # are still accepted.

How does comment line work in git commit message?

Polymerase
  • 6,311
  • 11
  • 47
  • 65
  • out of curiosity, why would you need an ignored line in your commit message? – jbu Feb 21 '17 at 03:50
  • @jbu git merge or git rebase generate an automatic commit message with a lot of lines beginning with #. I have noticed sometimes line beginning with # still make it into the log. May be there is a rule, that sometimes # is ignored, sometime not. I would like to know for sure to avoid confusion. – Polymerase Feb 21 '17 at 04:08
  • I'm aware of this but I'm struggling to see how adding ignored lines to a commit message is a valid usecase. – jbu Feb 21 '17 at 04:13
  • my guess is that everything not in the path pointed to by config variable commit.template is considered a valid part of the commit, whether there's a comment marker or not. Just a guess - I have no answer for you but at least that might give you a direction to research. – jbu Feb 21 '17 at 04:18
  • Is your SourceTree Git setting set to use the "system" Git? Or the embedded one? Also I wrote http://stackoverflow.com/a/14931661/6309. – VonC Feb 21 '17 at 05:29
  • 1
    The hash symbol works as commentary indicator only in the editor. If the commit message is set by `-m`, `-F`, `-C` that does not invoke the editor, the hash symbol is just an ordinary symbol. – ElpieKay Feb 21 '17 at 06:46
  • @ElpieKay This is the answer. Using `git commit` (without -m option) the VI editor opens and indeed there are full of prefilled lines with #. I have added a new comment lines beginning with # and there are all discarded. BTW, how does Git tell to the editor that those # lines are to be discarded? Can you write an answer so I can accept it as answer? – Polymerase Feb 23 '17 at 04:45
  • @VonC My SourceTree Git setting uses the "system" Git. – Polymerase Feb 23 '17 at 04:52

1 Answers1

3

# as a comment is not a rule of Git commit messages. Instead, it's a rule for writing commit messages via an editor.

AFAIK this is to allow Git to display instructions and other information to the commit author.

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
#       new file:   what
#

This is saved as .git/COMMIT_EDITMSG. When your editor closes, Git reads that file, strips out the comments (and other special things), and uses what's left as the commit message.

From the git-commit docs...

$GIT_DIR/COMMIT_EDITMSG

This file contains the commit message of a commit in progress. If git commit exits due to an error before creating a commit, any commit message that has been provided by the user (e.g., in an editor session) will be available in this file, but will be overwritten by the next invocation of git commit.

You can, btw, abort a commit by providing no uncommented lines.

If you use git commit -m, for example, there's no need for any of that and a message starting with a # is fine.

$ git ci -m '# message with a comment'
[master 7c6a630] # message with a comment
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 that
$ git log
commit 7c6a630a9c84fda585601edef0b18e7a8683dffa (HEAD -> master)
Author: Michael G. Schwern <schwern@pobox.com>
Date:   Wed Feb 22 20:51:36 2017 -0800

    # message with a comment
$ cat .git/COMMIT_EDITMSG
# message with a comment

git commit has an option to control this behavior, --cleanup. There are various modes which strip comments, cleanup whitespace, or do nothing. The default is "Same as strip if the message is to be edited. Otherwise whitespace." This can be controlled with the commit.cleanup config variable.

You can, if you really want to, use a commit-msg hook to make sure comments are always stripped.

Community
  • 1
  • 1
Schwern
  • 153,029
  • 25
  • 195
  • 336
  • @Shwern This becomes clearer. However, in the example you showed with `git commit -m '# message with a comment'`. The file `.git/COMMIT_EDITMSG` does contain a line starting with #. How come this time git doesn't ignore this # line? I am confused because you explained that *"Git reads that file, strips out the comments (and other special things), and uses what's left as the commit message"* – Polymerase Feb 23 '17 at 05:23
  • @Polymerase `git commit` which uses an editor reads from `COMMIT_EDITMSG`. I don't think `git commit -m` reads the message from the file, it already has it from the command line. Instead it writes to it should the commit fail. Anyway, since `git commit -m` is doing the committing, it knows it came via `-m` and doesn't need comments stripped. – Schwern Feb 23 '17 at 05:26
  • @Polymerase Ah ha! I found what you're looking for. `commit.cleanup`. See edits to the answer. – Schwern Feb 23 '17 at 05:31
  • 1
    @Shwern Just tested and confirm that `git commit --cleanup strip -m "# Line to ignore"` did abort the commit as the comment is removed and the commit could not proceed with an empty message. All this # comment business is not really critical but I am now relieved to finally understand the mechanism. Thanks. – Polymerase Feb 23 '17 at 05:43