154

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

brainimus
  • 10,586
  • 12
  • 42
  • 64
Nik
  • 1,605
  • 2
  • 11
  • 4
  • 8
    Finally, `git commit -a --allow-empty-message -m ''` won't even open an editor anymore. See [my answer below](http://stackoverflow.com/a/17365487/6309) – VonC Jun 28 '13 at 13:11
  • 4
    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 ""`. – tav Dec 13 '16 at 12:29

10 Answers10

169

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.

Zombo
  • 1
  • 62
  • 391
  • 407
Jeremy W. Sherman
  • 35,901
  • 5
  • 77
  • 111
  • 31
    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. – Armen Michaeli Feb 22 '14 at 16:39
  • 7
    @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. – Sergey Orshanskiy Jan 02 '15 at 23:33
  • 15
    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! – Jim Pivarski Jan 31 '16 at 14:00
  • `git commit -m "yea"` - Kinda sounds like Bill Lumbergh, "Ummm, yeah..." – Michael Lewis Jan 24 '17 at 22:59
  • 8
    @amn , sometimes the output of `git diff` is not self-explanatory, even when the committer believes it is. – cowlinator Apr 25 '18 at 20:30
  • Although I don't rule out that in some cases no commit message might be in order, generally it makes sense to provide summary. And if you're doing something out of the ordinary (which doesn't deserve a comment in the code), you might want to provide a detailed explanation. Or to provide some additional information, like a failed test output or something. You can think of summary as a function name, and of a detailed explanation as a comment. You aren't arguing for banning functions, @ArmenMichaeli?. Also moving some not really important comments from the code to the history... – x-yuri Mar 15 '23 at 11:41
  • ...might make the code a bit cleaner. But if you're using the history in a sort of like autosave fashion... Then what's the point? Well, that's what @JimPivarski's comment made me think about. It does seem like with documentation commit messages make less sense. But maybe not? I think that as we're forced to do thing faster and faster... we shouldn't give up on the history. Because one day you might want to find out, "Why or when did I change that?" But yeah, with documentation it might make less sense. Don't take it too personally, just sharing my thoughts. – x-yuri Mar 15 '23 at 11:41
40

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.

Zombo
  • 1
  • 62
  • 391
  • 407
dalvarezmartinez1
  • 1,385
  • 1
  • 17
  • 26
28

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 .

nik7
  • 806
  • 3
  • 12
  • 20
lackadaisical
  • 1,628
  • 18
  • 21
24

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.
Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
7

--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 ''.

Daniel Liuzzi
  • 16,807
  • 8
  • 52
  • 57
  • On Windows, I would try with double quotes: `-m ""` – VonC Nov 20 '20 at 21:25
  • 3
    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`. – Daniel Liuzzi Nov 21 '20 at 07:38
5

You don't need git to accomplish this. Creative use of a bash function will do the trick just fine. If you don't care about messages, just set a default one and forget it.

function gitcom() {
  git commit -m "my default commit message"
}

If you were feeling really adventurous you could add, commit and push with one command

function gitzap() {
  git add . && git commit -m "whatevs" && git push $1 $2
}

Which you would then run as

gitzap origin master

You could even get deeper and use parse_git_branch to save yourself some keystrokes there, or set a common default of "origin" and "master".

Steven Garcia
  • 2,814
  • 2
  • 24
  • 12
  • 1
    Could you provide some more details on how to set up this bash function? – adaam Oct 12 '15 at 11:57
  • 1
    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 – Steven Garcia Oct 13 '15 at 12:45
  • 2
    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` – Manuzor Aug 16 '17 at 05:57
  • 1
    in bash it's either `function gitcom {` or `gitcom() {` TMK, fix? –  May 19 '19 at 06:45
5

Git requires a commit to have a comment, otherwise it wont accept the commit.

You can configure a default template with git as your default commit message or can look up the --allow-empty-message flag in git. I think (not 100% sure) you can reconfigure git to accept empty commit messages (which isn´t such a good idea). Normally each commit should be a bit of work which is described by your message.

Daniel Kurka
  • 7,973
  • 2
  • 24
  • 43
  • 4
    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. – Jezen Thomas Sep 13 '16 at 17:05
2

I found the simplest solution:

git commit -am'save'

That's all,you will work around git commit message stuff.

you can even save that commend to a bash or other stuff to make it more simple.

Our team members always write those messages,but almost no one will see those message again.

Commit message is a time-kill stuff at least in our team,so we ignore it.

bronze man
  • 1,470
  • 2
  • 15
  • 28
2

I have the following config in my private project:

git config alias.auto 'commit -a -m "changes made from [device name]"'

That way, when I'm in a hurry I do

git auto
git push

And at least I know what device the commit was made from.

e18r
  • 7,578
  • 4
  • 45
  • 40
1

Building upon some other answers, I came up with the following:

git config --global alias.gromit '!git add --all && git commit --allow-empty-message -m ""'

This differs from the answer by dalvarezmartinez1 in that git add --all also adds new files, while the -a flag in git commit leaves them be. Also, I think that this alias fits the command much better. :-)

Future self, forgive me all the silent, quick, great commits to come.