Elijah Newren <[email protected]> writes:
> This patch cleanly applies to both 2.19.0 and pu. There are some related
> code cleanups that I'd like to make, but doing that cleanup conflicts with
> the various rewrite-rebase-in-C topics sitting in pu; since those are
> fairly lengthy, I really don't want to cause problems there, but I think
> SZEDER really wants this 2.19.0 regression fix before 2.20.0 and thus
> before those other topics.
Oh absolutely. Materials for 2.19.x maintenance track can and
should jump over other topics for 2.20 and later. Thanks for being
considerate.
> @@ -899,7 +899,7 @@ static int run_git_commit(const char *defmsg, struct
> replay_opts *opts,
> if ((flags & ALLOW_EMPTY))
> argv_array_push(&cmd.args, "--allow-empty");
>
> - if (opts->allow_empty_message)
> + if (!(flags & EDIT_MSG))
> argv_array_push(&cmd.args, "--allow-empty-message");
Hmph. I briefly wondered if an alternative logic would be better:
If and only the original commit being rewritten is empty,
then we allow the result to be empty.
But looking at EDIT_MSG would be more explicit and probably is a
better idea. That would allow you to abort a reword of a commit
whose message is empty.
The reason why I thought about the alt logic is because I am worried
about a use case where
$ GIT_EDITOR=: git rebase|cherry-pick ...
is used to say "I do not want you to go interactive, when the only
interaction needed from me is to edit the message---I am perfectly
happy with the messages of commits being replayed or ones you come
up with as the default". Because "--allow-empty-message" tends to
make things _less_ interactive, the worry is unfounded.
