Re: Cherry-pick dangles and forgets helpful advice in next

Phil Hord [off-list ref] writes:

Junio C Hamano wrote:

quoted

Instead of reverting the entire thing, perhaps we can fix the
regression like this.

With this, we no longer unconditionally give "--allow-empty" when we
run "git commit", when --allow-empty (which is only about commits
that are originally empty) is given to cherry-pick; specifically,
when the user did not ask for --keep-redundant-commit, we do not
give "--allow-empty" if the original commit is not.

Thinking about it again, I _think_ we do not even have to check if
the result is an empty commit ourselves ("git commit" will do that
for us anyway), so we might want to rip "is_empty_commit()" out of
the problematic patch and keep only "is_index_unmodified()" bit, but
for now I think this may be good enough.

Phil, does it fix your issue?

Yes, it appears to fix my issue.  I don't have the original condition in
play anymore, but it fixes the test case I cooked up earlier.

OK, I'm planning to merge the fix down before 1.7.11 final. It may
have broken the use case Neil wanted to support as a side effect (I
tried to be careful but I did not do anything beyond the test cases
as I do not deliberately add empty commits to my history); Neil may
want to double check the result.

Thanks.