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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html