1

I have my core.editor set to Sublime Text. However, all of my commits automatically fail and I am given the following:

Aborting commit due to empty commit message.

Even though it does open Sublime Text. Is there something else I need to do to prevent this, or will Sublime just not work for this?

Note, I am doing this all from the terminal.

Dan Lowe
  • 51,713
  • 20
  • 123
  • 112
RhythmInk
  • 513
  • 1
  • 4
  • 18
  • 1
    Possible duplicate of [How can I make Sublime Text the default editor for Git?](https://stackoverflow.com/questions/8951275/how-can-i-make-sublime-text-the-default-editor-for-git) – phd May 05 '18 at 14:06

2 Answers2

4

The problem is that the Sublime Text command-line tool by default tells the Sublime Text GUI to open a file, and then exits right away, even while the GUI still has the file open. There's an option, though, that'll tell the command-line tool to wait for the file to be closed in the GUI. That option is --wait (or -w for short). So if I try this:

: $; git config core.editor subl
: $; git commit

... I get the following -- with the first line showing briefly then getting erased and replaced by the second:

hint: Waiting for your editor to close the file... 
Aborting commit due to empty commit message.

You may or may not see the first line, as this all happens at about the same time as the Sublime Text GUI is becoming visible, and opening up the COMMIT_MESSAGE file. And when you return to the Terminal, you'll see only the second line.

But if I add the option to wait, it works. So I change the editor like so:

: $; git config core.editor 'subl -w'

And then if I do a git commit, and switch from Sublime Text to the Terminal without closing the COMMIT_MESSAGE file, I see:

: $; git commit
hint: Waiting for your editor to close the file...

And then if I go back and close the file (after writing in some text and saving it), I come back to see:

: $; git commit
[master 79d5a7b] Commit message I typed in Sublime Text GUI.
 1 file changed, 1 insertion(+), 1 deletion(-)
lindes
  • 9,854
  • 3
  • 33
  • 45
1

If you're exiting without changing the message, you should be aware that you actually have to type something in.

The same thing happens to me (with gedit) if I don't actually enter something over and above the comment lines it starts with (merges are okay since they automatically add the non-comment "merging a to b"-like text).

However, if your editor is actually starting but the git commit carries on while it's open, then there's an issue with the way the editor is being started.

There's a known issue with Sublime Text in that programs that start it can't always correctly identify that it's still running. I think that may be due to the fact that the command line tool simply tells the GUI program to open the file (starting it first if needed), then the command line tool will exit.

Hence, git will assume it's finished and, since the file hasn't been changed at that point, it gives you that error message.

In terms of fixing that issue, I believe Sublime Text added a -w flag to ensure this didn't happen.

In any case, I prefer explicitly entering a message on the command line with something like:

git commit -m 'fixed my earlier screw-up'

so that I don't have to worry about editors and such.

paxdiablo
  • 854,327
  • 234
  • 1,573
  • 1,953
  • 1
    The `-w` / `--wait` flag to Sublime is, it seems to me, the key to answering the question -- not typing something in could also create the abort, but I doubt that's what's going on. – lindes May 05 '18 at 02:25
  • Also, while using `-m` is entirely reasonable and common practice for many situations, one nice thing about using a full-blown editor is that one can have multi-line commit messages; especially useful for commits that make complex changes, or are complex merges, etc. – lindes May 05 '18 at 02:55
  • @lindes, the middle section states clearly enough that case, I believe. And the end section is simply stating how *we* do it, it's really tangential to the question. Since we actually have the advantage of using JIRA alongside git, we include the JIRA issue in the commit text as well, and the JIRA issue itself details all the reasoning behind the changes made for a given issue - git holds only a short descriptor. – paxdiablo May 05 '18 at 07:37