Why does GitHub invite me to enter two commit messages instead of just one?
This may be a basic question but I thought it would be worth asking.
On GitHub, when you add a file to a repository by clicking the plus
sign next to the repository’s name, you get a text area where you can enter the contents of the file, followed by two commit messages:
- Identifying conflicts and consequences of forcing a push
- Notorious Git Error: remote rejected (failed to lock)
- Does the parent git repository contain the full source tree of a git submodule?
- How to git patch the whole branch/tag in git to apply it on another repository which is not updated?
- Simplest command to grab a read-only copy of a git repository?
- What's the unstaged changes in github?
However, when I use
git commit -m, I can only specify one message. Hence my confusion…
Does the optional extended description on GitHub end up in the repository or not? After cloning the GitHub repository in question, how would I view such messages?
As far as I know,
git commit only allows you to specify one message (using the
-m flag), but maybe I’m missing something. Is there a way to specify a second
extended message, somehow?
3 Solutions collect form web for “Why does GitHub invite me to enter two commit messages instead of just one?”
[…] two commit messages […]?
Two?! No; only one. The contents of those two text fields are combined to produce a single commit message. GitHub uses two text fields instead of one only to trick users into formatting their commit messages well.
git-commit man page has a section entitled Discussion, which contains the following guidelines about the preferred format of commit messages:
Though not required, it’s a good idea to begin the commit message with
a single short (less than 50 character) line summarizing the change,
followed by a blank line and then a more thorough description. The
text up to the first blank line in a commit message is treated as the
commit title, and that title is used throughout Git.
When a user is about to create a commit directly on the GitHub site, she’s invited to fill in two text fields:
- The first text field corresponds to the single short (less than 50 character) line summarizing the change.
- The second text field corresponds to the more thorough description.
By providing two text fields instead of one, GitHub helps the user follow the prescribed commit-message policy. Note, in particular, that you get a warning message if the number of characters typed in the first dialog box exceeds 50:
If you then run
git fetch in your local repo and
git log, you will see that the commit message is composed of the contents of both text fields:
$ git log commit 0ef92f231cfbf2d4faf8f006e8ba19fc8169c099 Author: Jubobs xxxxxxxxxxxxxx Date: Wed Oct 1 10:39:15 2014 +0100 write 'Hello, World!' - foo - bar - baz
OK, I’ve cloned the GitHub repository with “git clone”
and by running a “git log” or “git commit –amend” I
can now see that the message consists of the first
50 character commit message line followed by a space
followed by the optional extended message.
GitHub has done a magnificent job of “GUIfying” many of the operations of Git.
As you have stated, the ‘git -m “message here” will provide what is known as a “short message” and it appears as the title when you use
But, git supports much more text – which is stored as part of the commit. That is what GitHub is providing for you in that second edit field; a chance to add a bit more detail to the commit message.
When you have the repository locally (as a result of
git clone) you can see that ‘extra’ data if you modify the log output (for example
git log --pretty==fuller).