Git commit opens blank text file, for what?

In all the Git tutorials I've read they say that you can do:

git init
git add .
git commit

When I do that I get a big text file opened up. None of the tutorials seem to address this, so I don't know what to do with the file or what to put in it if anything.

You're meant to put the commit message in this text file, then save and quit.

You can change the default text editor that git uses with this command:

git config --global core.editor "nano"

You have to change nano to whatever command would normally open your text editor.

As mentioned by Ben Collins, without the -m "..." argument to type the commit inline (which is generally a bad idea as it encourages you to be brief), this "big text file" that is opened up is a window in which to type the commit message.

Usually it's recommended to write a summary in the first line, skip a line, and then write more detailed notes beneath; this helps programs that do things like email the commit messages with an appropriate subject line and the full list of changes made in the body.

Instead of changing the EDITOR shell variable, you can also change the editor used by adding the additional lines in your ~/.gitconfig file:

[core]
	editor = emacs
	excludesfile = /Users/will/.gitignore

That second line actually has nothing to do with your problem, but I find it really useful so I can populate my ~/.gitignore file with all those filetypes I know I'll never, ever, want to commit to a repository.

The text file that is being opened is a summary of the current commit operation. The git commit drops you into this file so the you can add a commit message at the top of the file. Once you've added your message just save and exit from this file.

There is also a "-m msg" switch on this command that allows you to add the commit message on the command line.

If you’re on Mac OS X and using BBEdit, you can set this up as the editor of choice for commit messages:

git config --global core.editor "bbedit -w"

Once finished edit, save and close the file and git will use it for the comments.

Assuming that your editor defaults to vi/vim, you can exit the commit message editor by typing:

:x

which will save and exit the commit message file. Then you'll go back to the normal git command section.

More vi commands:
http://www.lagmonster.org/docs/vi.html

As all have said this is just where you add your commit comment - but for some it may still be confusing esp if you have not configured your editor settings, and you are not aware of what VI is : then you could be in for a shock, because you will think you are still in the GIT-Bash

In that case you are in fact in a text editor with some interesting ways of dealing with things and this set of commands may help you out so that you can get past your first commit and then configure an editor you are familiar with or use it as an opportunity to learn how to use it.

The -m option to commit lets you enter a commit message on the command line:

git commit -m "my first commit"

When you create a new commit, git fires up a text editor and writes some stuff into it.

Using this text editor, the intention is for you to write the commit message that will be associated with your feshly created commit.

After you have finished doing so, save and exit the text editor. Git will use what you've written as the commit message.

The commit message has a particular structure, described as follows:

The first line of the commit message is used as the message header (or title). The preffered length of the commit header is less than 40 characters, as this is the number of characters that github displays on the Commits tab of a given repository before truncating it, which some people find irritating.

When composing the header, using a capitalized, present tense verb for the first word is common practice, though not at all required.

One newline delineates the header and body of the message.

The body can consist whatever you like. An overview of the changes introduced by your commit is reasonable. Some third party applications use info included the body of commit messages to set off various kinds of hooks (I'm thinking Gerrit and Pivotal Tracker, to name two).

Here's a short and sweet example. A leading # denotes a comment.

Gitignore index.pyc

Ignore gunicorn generated binary file
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch dev
# Your branch is ahead of 'origin/dev' by 10 commits.
#   (use "git push" to publish your local commits)
#
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   .gitignore
#

Here one Mr. Torvalds opines on what makes a good commit.

And here Tpope does likewise.

As stated in several other answers, changing the default editor is a one-liner on the command line.

For my preference:

git config --global core.editor "vim"

Try Escape then ZZ, after you're done typing your message. As others have said when you run that commit command it actually runs a text editor to enter the message into. In my case (OS X) it was VI, which I figured out after some digging around. In that case, hit Escape to go into "command" mode (as opposed to INSERT mode) the enter ZZ. I'm sure there are other ways of accomplishing the task but that did it for me. Having never used VI or emacs it wasn't readily apparent to me and wasn't mentioned in any of the beginner guides I was using. Hopefully this helps.

The git commit command will open up the editor specified in the EDITOR environment variable so you can enter a commit comment. On a Linux or BSD system, this should be vi by default, although any editor should work.

Just enter your comments and save the file.

I was confused because I kept trying to enter a filename after the :w in VIM. That doesn't trigger the commit. Instead I kept getting a message "Aborting commit due to empty commit message." Don't put a filename after the :w. :w saves the file to .git/COMMIT_EDITMSG by default. Then :q to exit to complete the commit. You can see the results with git log.

Now that I've changed my editor to emacs, everything work fine.

But before I set this, "git commit -a" did open gedit, but also immediately ended with a "Aborting commit due to empty commit message.". Saving the file from gedit had no effect. Explicitly setting the editor with "git config --global core.editor "gedit"" had the same result.

There's nothing wrong with emacs, but out of curiosity why doesn't this work with gedit, and is there any way to get it to work?

Thanks.

For those of you using OS X I found this command to work well:
git config --global core.editor "open -t -W"

which will force git to open the default text editor (textedit in my case) and then wait for you to exit the application. Keep in mind that you need to "Save" and then "Quit" textedit before the commit will go through. There are a few other commands you can play around with as detailed on this page:

[Apple Developer Library - Open Command][1]

[1]: http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/open.1.html "Apple Developer Library - Open Command"

You can also try git config --global core.editor "open -e -W" if you want git to always open textedit regardless of what the default editor is.

When doing revision control, you should always explain what the changed you made are. Usually the first time you're have a comment such as "Initial Commit."

However in the long run you want to make a good comment for each commit. You will want something of the form:

> Added experimental feature x. > > X will increase the performance of > feature Y in condition Z. Should you > need X activate it with the -x or > --feature-eks switches. This addresses feature request #1138.

Yeah, make sure you have a sensible editor set. Not sure what your default editor will be but if, like me, it is nano (it will say so somewhere near the top after you type commit) you just need to type in a comment and then hit Ctrl-X to finish. Then hit y, followed by enter to affirm the commit.

Also, if you want to see a simple list of the files you'll be committing rather than a huge diff listing beforehand try

git diff --name-only

Being new to Terminal as well, "Escape and then ZZ" worked for me, I've been having this issue for months and also couldn't find a way around it.

Thanks TheGeoff for your simple advice!

The following is probably the easiest way to commit all changes:

git commit -a -m "Type your commit message here..."

Of course there are much more detailed ways of committing, but that should get you started.