Git actually checks the exit code of whatever editor you have configured and outputs that error message if it's non-zero.
I couldn't replicate the problem with your commands but you may have better luck. Simply run vim
normally (i.e., not via git
), enter the :Wq
and :wq
commands (and whatever else you did in between those two), then check the exit code with (for Linux) echo $?
.
If that's not zero, you at least have a repeatable test you can use for further investigation, at which point you can start experimenting with vim
options (as shown in this question for example).
You could also opt for a different editor which doesn't return non-zero. There's probably no reason to need the massive power of Vim for composing what are (hopefully) one-liner commit messages.
In fact, I don't use any editor, instead relying on the command-line bevaviour only. For one-liners:
pax$ git commit -m "Fixed my co-worker's atrocious code :-)"
or, more more complex messages:
pax$ git commit -F -
(reading log message from standard input)
Fixed my co-worker's atrocious code, specifically:
- no comments;
- unreadable formatting;
- bad variable names.
<CTRL-D>
As to how you easily get at the comment you just tried to use, that should be stored in .git/COMMIT_EDITMSG
so you can just use:
git commit -F .git/COMMIT_EDITMSG
(or -eF
if you want to check or further edit the message).
command -bang Wq wq<bang>
. (If you ever pass arguments to:wq
you can instead use an abbreviation:cabbrev <expr> Wq (getcmdtype() == ':' && getcmdpos() == 3) ? 'wq' : 'Wq'
) – Rich May 4 '18 at 15:12:Wq
typo is related to the git error. As for recovering,git commit
starts the editor on.git/COMMIT_EDITMSG
, so check the contents of that file. You can usegit commit -eF .git/COMMIT_EDITMSG
to continue with that message. – Martin Tournoij May 6 '18 at 18:36COMMIT_EDITMSG
indeed does have the message I meant to use. That's how I can recover from this, thanks. Any thoughts on why (or how) git interpretes vi had a problem? Technically, yes, it did have a problem and apparently the strategy is to be more safe than sorry; but where git gets "vi had a problem" status? From some metadata/variable, return state or what? I mean: is it some standard vi/vim way or just (too) fuzzy logic on git's part? – Jari Keinänen May 7 '18 at 9:47