]> git.ipfire.org Git - thirdparty/git.git/commit - t/t7501-commit-basic-functionality.sh
commit: do not ignore an empty message given by -m ''
authorJeff King <peff@peff.net>
Thu, 7 Apr 2016 19:56:26 +0000 (12:56 -0700)
committerJunio C Hamano <gitster@pobox.com>
Thu, 7 Apr 2016 20:25:12 +0000 (13:25 -0700)
commit27014cbc04e369624f6c1754b72ef4eddb911166
tree3e06c2a9b5894ff8a0e7e1269ec8498cb166f9f2
parent178e8143b4f79290b3ffe40fe2ebf769fccc1ab7
commit: do not ignore an empty message given by -m ''

When f9568530 (builtin-commit: resurrect behavior for multiple -m
options, 2007-11-11) converted a "char *message" to "struct strbuf
message" to hold the messages given with the "-m" option, it
incorrectly changed the checks "did we get a message with the -m
option?" to "is message.len 0?".  Later, we noticed one breakage
from this change and corrected it with 25206778 (commit: don't start
editor if empty message is given with -m, 2013-05-25).

However, "we got a message with -m, even though an empty one, so we
shouldn't be launching an editor" was not the only breakage.

 * "git commit --amend -m '' --allow-empty", 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.

Correct these by checking have_option_m, which the earlier 25206778
introduced to fix the same bug.

Reported-by: Adam Dinwoodie <adam@dinwoodie.org>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/commit.c
t/t7501-commit.sh