Phil Hord <hordp@xxxxxxxxx> writes:
> Junio C Hamano wrote:
>
>> 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.
--
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