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?
Enter git add --all at the command line prompt in your local project directory to add the files or changes to the repository. Enter git status to see the changes to be committed. Enter git commit -m '<commit_message>' at the command line to commit new files/changes to the local repository.
On the command line, navigate to the repository that contains the commit you want to amend. Type git commit --amend and press Enter. In your text editor, edit the commit message, and save the commit.
The quickest way to write a git commit is to use the command git commit -m "Git commit message here" . This is not recommended for commits, however, because it provides limited description of what was changed. Essentially, a git commit should explain what and why a change has been made.
You can use commit in multiple ways to commit changes to your repository, but every commit requires a log message. You can add a message by adding -m "your message". The message can be any valid string. You can also specify multiple paragraphs by passing multiple -m options to git commit.
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.
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.
As mentioned by Tom Morris, use a commit template.
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.
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.
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.
You can tweak the commit message via the prepare-commit-message
hook.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With