How do I add project-specific information to the Git commit comment?

Question

With Git, if you are committing, it includes a section under the commit message that is commented out. This contains instructions on writing a commit message as well as a list of files that are changing. Like this:

# 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:
#   (use "git reset HEAD <file>..." to unstage)
#
#       modified:  important-file.txt 
#
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   some-other-thing.txt
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       untracked.txt

Is it possible to add further material to this file? One clear use case is for those using issue tracking software like Trac, Redmine and the like is specifying extra syntactical elements. Redmine users, for instance, can include the issue number and some special keywords to mark issues as resolved: the keywords are "refs" (and "references") and "fixes" (or "closes") - but I often find it difficult to remember the keywords.

It would be handy, then, if one could append some project-specific text at the bottom of the commit instructions.

Is there any existing way of doing this or do I need to hack one in? As a side issue, do any other VCSes (like Mercurial) have similar behaviour?

Answer 1

I'm pretty sure you could use a prepare-commit-msg hook for this. Take a look at githooks for more information.

Answer 2

You can tweak the commit message via the prepare-commit-message hook.

Answer 3

Option 1:

As others have mentioned, the direct way to do this with Git is the prepare-commit-message hook.

However, there are issues with that strategy that must be considered. From Chapter 7.4 of Pro Git:

[Client-side hook scripts] aren’t transferred with a clone of a project, you must distribute these scripts some other way and then have your users copy them to their .git/hooks directory and make them executable. You can distribute these hooks within the project or in a separate project, but there is no way to set them up automatically.

Option 2:

As mentioned by Tom Morris, use a commit template.

Option 3:

You could do a custom build of Git which includes your additional instructions. The instructions included in the current commit message are hard-coded in the Git source code. See $GIT_SRC/builtin/commit.c starting at line 655.

This method is probably not preferred since you would have to apply the patch every time a new version of Git is released.

Option 4:

Create a patch for Git which adds this feature and submit it to the mailing list. If you (or others) decide to try this, I would first ask for advice from the list on how to proceed.

---

Mercurial:

Hook scripts in Mercurial behave in a similar manner. From Chapter 10 of Mercurial: The Definitive Guide:

In Mercurial, hooks are not revision controlled, and do not propagate when you clone, or pull from, a repository. The reason for this is simple: a hook is a completely arbitrary piece of executable code. It runs under your user identity, with your privilege level, on your machine.

It would be extremely reckless for any distributed revision control system to implement revision-controlled hooks, as this would offer an easily exploitable way to subvert the accounts of users of the revision control system.

Answer 4

I used a commit.template (as described here). I could have used a prepare-commit-msg hook, but a commit template does the job slightly easier, plus I can keep the commit template in the version control for the project.