Re: [PATCH v3 1/4] git-cherry-pick: add allow-empty option

Neil Horman [off-list ref] writes:

...  What do you say to my proposal regarding the splitting of the device
dependent on how we were executed?  It seems we can't use a single advice string
in this case, as no matter which we choose there is a use case in which it fails
to make sense.

When your cherry-pick got --allow-empty, it should pass --allow-empty to
its inner invocation of commit if it is picking an originally empty
commit, and this advice will not trigger because commit will happily
commit the no-change change.

When your cherry-pick got --allow-empty but not --keep-unnecessary-commit,
its inner invocation of commit must not pass --allow-empty if it is _not_
picking an originally empty commit.  Then the inner commit will fail if it
auto resolves to no change, and the user sees the advice.  The current
advice text is appropriate for this case.

When your cherry-pick did not get either of these flags, its inner
invocation of commit must not pass --allow-empty.  The user sees the
advice when the auto resolved result matches HEAD from the commit invoked
by cherry-pick.  The current advice text is fine for this case, as we say
"possibly", not "we definitely know it was due to conflict resolution".

Or your cherry-pick may have failed due to a conflict, regardless of the
options like --allow-empty or --keep-unnecessary-commit given to it, and
the user may have run commit after resolving the conflict.  The current
advice text is fine for this case, too, as we say "possibly", and it
indeed is what just happened.

So I do not think you need to change anything with respect to the advice
message.

Am I missing some other cases?