Start a Git commit message with a hashmark (#)

Question

Git treats lines starting with # (hash, number sign, octothorpe, pound sign) as comment lines when committing. This is very annoying when working with a ticket tracking system, and trying to write the ticket number at the beginning of the line, e.g.

#123 salt hashed passwords

Git will simply remove the line from the commit message. Is there a way to escape the hash? I tried \ and !, but nothing works. White space before # is preserved, so that's not a working solution to the problem either.

Answer 1

This behaviour is part of git commit's default 'clean-up' behaviour. If you want to keep lines starting with # you can use an alternative clean-up mode.

E.g.

git commit --cleanup=whitespace

If you do this you have to be careful to remove all # lines that you don't want to appear in the commit.

Answer 2

It just suffices to start the commit message with a space char just before the # char.

Then git stops regarding the line as a comment and github can use the hashed ticket number without any problems.

vim's default syntax highlighting even suggests the feature by changing the color from commentish to contentish.

Answer 3

If you're doing an interactive rebase, then when you save your commit message with nothing in it (because the # at the beginning has made it a comment and therefore it's been ignored) git will show you what to do:

Aborting commit due to empty commit message.
Could not amend commit after successfully picking 5e9159d9ce3a5c3c87a4fb7932fda4e53c7891db... 123 salt hashed passwords
This is most likely due to an empty commit message, or the pre-commit hook
failed. If the pre-commit hook failed, you may need to resolve the issue before
you are able to reword the commit.
You can amend the commit now, with

        git commit --amend

Once you are satisfied with your changes, run

        git rebase --continue

So, just amend the message:

git commit --amend -m "#123 salt hashed passwords"

and continue the rebase:

git rebase --continue

Answer 4

Answers here are good and detailed, but for a git noob like me customizing git config options isn't so obvious. Here is an example to change from # to ; for comment characters:

git config core.commentChar ";"

That's all you need to do.

Answer 5

git commit --cleanup=scissors should be used. It's added to Git v2.0.0 on 2014.05.21

from git commit --help

--cleanup=<mode>
  scissors
    Same as whitespace, except that everything from (and including) the line
    "# ------------------------ >8 ------------------------" is truncated if the message
    is to be edited. "#" can be customized with core.commentChar.

Answer 6

Use a different prefix for the ticket number. Or prepend a word to the ticket number, like "Bug #42". Or prepend a single space character to the line; if you wish to remove that whitespace you can add a commit-hook for that.

I personally would rather not have this sort of commit message manipulation done by a hook because it can be very irritating when it triggers when you don't want it to. The easiest solution is probably to re-think the problem.

Answer 7

You can use the command line option -m:

git commit -m "#123 fixed"

Answer 8

Note that, since git1.8.2 (February 2013), you can use a different character than '#' for the commented line in the commit message.

That allows you to use '#' for your bug number reference.

Various "hint" lines Git gives when it asks the user to edit messages in the editor are commented out with '#' by default.

The core.commentChar configuration variable can be used to customize this '#' to a different character.

---

In theory, you could put a core.commentChar word (multiple characters), but git 2.0.x/2.1 will be stricter (Q3 2014).

See commit 50b54fd by Nguyễn Thái Ngọc Duy (pclouds):

config: be strict on core.commentChar

We don't support comment strings (at least not yet). And multi-byte character encoding could also be misinterpreted.

The test with two commas is updated because it violates this. It's added with the patch that introduces core.commentChar in eff80a9 (Allow custom "comment char" - 2013-01-16). It's not clear to me why that behavior is wanted.

---

git 2.0.x/2.1 (Q3 2014) will add an automatic selection for core.commentChar:
See commit 84c9dc2

When core.commentChar is "auto", the comment char starts with '#' as in default but if it's already in the prepared message, find another char in a small subset. This should stop surprises because git strips some lines unexpectedly.

Note that git is not smart enough to recognize '#' as the comment char in custom templates and convert it if the final comment char is different.
It thinks '#' lines in custom templates as part of the commit message. So don't use this with custom templates.

The list of candidate characters for "auto" are:

# ; @ ! $ % ^ & | :

That means a command like git commit -m '#1 fixed issue' will automatically switch the commentChar to ';', because '#' was used in the commit message.

---

See "Making a hash of things – using #s in Git commit messages" by Tom Wright

The Stackoverflow answer I linked to above also mentions a feature in Git that will choose a comment character automatically, based on the characters you use in commit messages.

git config --global core.commentChar auto

Sounds great right?
Unfortunately, it only changes the comment character based on commits made after you turn it on; it doesn’t use your commit history to inform the choice.

To my mind, this is a great feature hobbled by poor execution.
It seems like a feature that would be effective only if it were on by default:

• One group of people will simply avoid using hashes in commits because they are familiar with the consequences.
• Others (like us) will only realise they need to change the comment character when they need to do a rebase. It doesn’t make sense in this situation to add a new commit just to trigger the desired behaviour.
• A third group of people will consciously accept early on that they need to change the default comment character and will simply choose an alternative.

In other words, having this feature available as a non-default option helps virtually no-one.
Since having it on by default would do nothing to harm any users, and would remove a pain point for some users, I can’t work out why this isn’t the case.
Git isn’t famed for its usability, but to have a fix available and not to turn it on seems gratuitously user-hostile.

---

Note: Git 2.41 (Q2 2023) adds:

See commit d3b3419 (27 Mar 2023) by Kristoffer Haugsbakk (LemmingAvalanche).
^{(Merged by Junio C Hamano -- gitster -- in commit 5c93cfd, 31 Mar 2023)}

config: tell the user that we expect an ASCII character

^{Signed-off-by: Kristoffer Haugsbakk}

Commit 50b54fd ("config: be strict on core.commentChar", 2014-05-17, Git v2.1.0-rc0 -- merge listed in batch #2) notes that “multi-byte character encoding could also be misinterpreted”, and indeed a multi-byte codepoint (non-ASCII) is not accepted as a valid core.commentChar.

The message is now:

core.commentChar should only be one ASCII character
                                    ^^^^^

---

This is confirmed with Git 2.45 (Q2 2024), batch 7: The "core.commentChar" configuration variable only allows an ASCII character, which was not clearly documented before.

See commit fb7c556 (05 Mar 2024) by Kristoffer Haugsbakk (LemmingAvalanche).
^{(Merged by Junio C Hamano -- gitster -- in commit 26ab20c, 14 Mar 2024)}

config: document core.commentChar as ASCII-only

^{Reported-by: Manlio Perillo
Signed-off-by: Kristoffer Haugsbakk}

d3b3419 ("config: tell the user that we expect an ASCII character", 2023-03-27, Git v2.41.0-rc0 -- merge listed in batch #6) updated an error message to make clear that this option specifically wants an ASCII character but neglected to consider the config documentation.

git config now includes in its man page:

messages consider a line that begins with this ASCII character

Answer 9

! is a history expansion that's why it didn't worked.

History expansions are introduced by the appearance of the history expansion character, which is ! by default.

You can use $ with single ' quotes (Escape a Single Quote in Single Quote String in Bash):

$ git commit -m $'#228 update to a new version! margin of error is 33% | 33^*0.22;'
# commit message: #228 update to a new version! margin of error is 33% | 33^*0.22;

$ git commit -m $'docs!: new API reference for GPS horse navigation'
# commit message: docs!: new API reference for GPS horse navigation

If used without $ and ' but with ":

$ git commit -m "docs!: new API reference for GPS horse navigation"
bash:  : unrecognized history modifier

If used with " and escape \ (\ will still be there or I was doing something wrong):

$ git commit -m "docs\!: new API reference for GPS horse navigation"
# commit message: docs\!: new API reference for GPS horse navigation

Answer 10

All my commits starts with #issueNumber so I put this boilerplate to my vim .git/hooks/commit-msg:

NAME=$(git branch | grep '*' | sed 's/* //') 
echo "$NAME"' '$(cat "$1") > "$1"

So let's suppose we have branch #15 and we make commit message add new awesome feature. With this approach final commit message will be #15 add new awesome feature.