Subject: Cherry-picking commits with empty messages

From: Chris Webb <[email-masked]>
Date: Wed, 1 Aug 2012 12:16:59 +0100

Whilst doing some extra sanity checking of my git-rebase--interactive.sh
patch yesterday, I came across a behaviour which has been present for some
time, but seems surprising. You can reproduce with

  $ git init -q foo && cd foo
  $ touch one && git add one && git commit -q -m one
  $ touch two && git add two && git commit -q -m two
  $ touch three && git add three && git commit -q -m '' --allow-empty-message
  $ touch four && git add four && git commit -q -m '' --allow-empty-message
  $ git rebase -i HEAD~3 # and swap the two commits with empty messages
  Aborting commit due to empty commit message.
  Could not apply 59a8fde... 

This happens on my ancient laptop which is apparently running 1.7.8.3, as well
as current master, so is unconnected to recent changes.

The reason is that git cherry-pick won't pick a commit with an empty commit
message, even when that message is unmodified from the original:

  $ git rebase --abort
  $ git checkout -q HEAD~2
  $ git cherry-pick 59a8fde
  Aborting commit due to empty commit message.

I can see that this check could make sense when the message has been
modified, but it seems strange when it hasn't, and isn't ideal behaviour
when called from rebase -i. (We otherwise make sure we call git commit with
--allow-empty-message to avoid problems with reordering or editing empty
commits.)

I could just remove the check in the 'message unmodified' case with
something like

diff --git a/sequencer.c b/sequencer.c
index bf078f2..cf8bc05 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -306,6 +306,7 @@ static int run_git_commit(const char *defmsg, struct replay_opts *opts,
 	if (!opts->edit) {
 		argv_array_push(&array, "-F");
 		argv_array_push(&array, defmsg);
+		argv_array_push(&array, "--allow-empty-message");
 	}
 
 	if (allow_empty)

but perhaps there are other users of the sequencer for whom this check is
desirable? If so, would an --allow-empty-message to git cherry-pick be a
better plan, which git rebase -i can use where appropriate?

Best wishes,

Chris.