Git commit with no commit message

Question

How can I commit changes without specifying commit message? Why is it required by default?

Solution 1

git generally requires a non-empty message because providing a meaningful commit message is part of good development practice and good repository stewardship. The first line of the commit message is used all over the place within git; for more, read "A Note About Git Commit Messages".

If you open Terminal.app, cd to your project directory, and git commit -am '', you will see that it fails because an empty commit message is not allowed. Newer versions of git have the
--allow-empty-message commandline argument, including the version of git included with the latest version of Xcode. This will let you use this command to make a commit with an empty message:

git commit -a --allow-empty-message -m ''

Prior to the --allow-empty-message flag, you had to use the commit-tree plumbing command. You can see an example of using this command in the "Raw Git" chapter of the Git book.

Solution 2

And if you add an alias for it then it's even better right?

git config --global alias.nccommit 'commit -a --allow-empty-message -m ""'

Now you just do an nccommit, nc because of no comment, and everything should be commited.

Solution 3

When working on an important code update, if you really need an intermediate checkpoint you might just do:

git commit -am'.'

or shorter:

git commit -am.

This adds a commit with the message .

Solution 4

Note: starting git1.8.3.2 (July 2013), the following command (mentioned above by Jeremy W Sherman) won't open an editor anymore:

git commit --allow-empty-message -m ''

See commit 25206778aac776fc6cc4887653fdae476c7a9b5a:

If an empty message is specified with the option -m of git commit then the editor is started.
That's unexpected and unnecessary.
Instead of using the length of the message string for checking if the user specified one, directly remember if the option -m was given.

---

git 2.9 (June 2016) improves the empty message behavior:

See commit 178e814 (06 Apr 2016) by Adam Dinwoodie (me-and).
See commit 27014cb (07 Apr 2016) by Jeff King (peff).
^{(Merged by Junio C Hamano -- gitster -- in commit 0709261, 22 Apr 2016)}

commit: do not ignore an empty message given by -m ''

• "git commit --amend -m '' --allow-empty-message", even though it looks strange, is a valid request to amend the commit to have no message at all.
  Due to the misdetection of the presence of -m on the command line, we ended up keeping the log messsage from the original commit.
• "git commit -m "$msg" -F file" should be rejected whether $msg is an empty string or not, but due to the same bug, was not rejected when $msg is empty.
• "git -c template=file -m "$msg"" should ignore the template even when $msg is empty, but it didn't and instead used the contents from the template file.

Solution 5

--allow-empty-message -m '' (and -m "") fail in Git 2.29.2 on PowerShell:

error: switch `m' requires a value

(oddly enough, with a backtick on one side and a single quote on the other)

---

The following works consistently in Linux, PowerShell, and Command Prompt:

git commit --allow-empty-message --no-edit

The --no-edit bit does the trick, as it prevents the editor from launching.

I find this form more explicit and a bit less hacky than forcing an empty message with -m ''.

View more solutions

Comments

[VonC]

Finally, git commit -a --allow-empty-message -m '' won't even open an editor anymore. See my answer below

[tav]

On Windows this command git commit -a --allow-empty-message -m '' makes commit with commit message "''", so it is better to use this command instead: git commit -a --allow-empty-message -m "".

[Armen Michaeli]

I think the sentence "providing a meaningful commit message is part of good development practice" is just wrong - one can say that providing a meaningful commit message is considered to be part of good development practice, as the statement is divisive anyway - I for one believe that less information sometimes leads to less confusion, especially since git obviously stores the actual changes to the repository, and a git diff will show the interested party exactly what a commit contains, without relying on human written descriptions. Machines should save us from labor where possible.

[Sergey Orshanskiy]

@amn, I also just started wondering about all those tens of thousands of well-written commit messages that I have written that will never ever be read by anyone. For me now the value of this habit is that it forces me to look through the changes in an attempt to describe them, and this sometimes makes me notice bugs. You are right, though. I'll consider paying more attention to the code and less to the commit message.

[adaam]

Could you provide some more details on how to set up this bash function?

[Steven Garcia]

Assuming you are on OSX or Linux, you can copy these functions and place them in your .profile (should be in your home folder, if not then create it). Open up a new console window and those commands will be available to you. Any changes made to these files will require you to refresh the bash session so you can speed things along by adding the following aliases to that file: alias ea="subl ~/.profile" # subl is my text editor, substitute with your own alias er="source ~/.profile" # this will reset Now when you want to add shortcuts you just type "ea" (edit aliases) And to refresh er

[Jim Pivarski]

Git is not just used for code development anymore. When I'm updating a GitHub wiki page or an Overleaf LaTeX document, there's usually nothing to say because I'm updating documentation. Everything semantically meaningful about the change is contained in the diff. I've actually found myself using the text of the change as the commit message itself: completely redundant!

[Jezen Thomas]

Not sure why this answer was down-voted. I agree that forcing Git to accept empty commit messages, or using a message like ‘save’, is a bad idea. Stop fighting it, and just learn the damn tool.

[Michael Lewis]

git commit -m "yea" - Kinda sounds like Bill Lumbergh, "Ummm, yeah..."

[Manuzor]

If you called the scripts git-com and git-zap (without extensions) and placed them somewhere git can find them (i.e. somewhere in your PATH), git treats them like regular git commands and you can invoke them like this: git com, git zap origin master

[cowlinator]

@amn , sometimes the output of git diff is not self-explanatory, even when the committer believes it is.

[fishinear]

And what does that do?

[lackadaisical]

Adds a commit with the message '.'

[Admin]

in bash it's either function gitcom { or gitcom() { TMK, fix?

[TheTechRobo Stands for Ukraine]

I use this method when I have literally no recollection of what I put in a commit and am too lazy to diff it all.

[VonC]

On Windows, I would try with double quotes: -m ""

[Daniel Liuzzi]

I did. They fail in PowerShell as well (they work in command prompt, but I don't use that.) Not having to remember a different syntax for every platform is why I prefer --no-edit.

[scotscotmcc]

I had to add a blank space in the "message", so it was ... -m " "'

[Tharindu Sathischandra]

Yeah -m. works great! I use this to create temporary commits on my wip branch and finally merge that wip branch with --squash by creating the real commit message.