Re: cherry-pick --no-commit does not work well with --continue in case of conflicts

[Junio C Hamano <gitster@pobox.com>]

Ilya Kantor <iliakan@gmail.com> writes:

> P.S. I assume, `cherry-pick -n <commits>` is meant to merge given
> commits' changes into the current working directory and the index,
> without making new commits, for any given set of commits, hope that's right?

Hmph.

One step in cherry-pick should refuse to start when HEAD and the index
does not match, even though it is perfectly OK if the working tree
files do not match the index, as long as such local changes do not
interfere with the change the cherry-pick tries to bring in.

The requirement for the index to be clean wrt the HEAD is
fundamental.  When any merge-y operation like cherry-pick, apply -3,
checkout -m, etc., happens, we would want to

 * store the cleanly automerged contents to the index

 * store common-ancestor, ours and theirs for conflicted merge to
   the stages in the index.

and being able to safely say "git reset" (not "reset --hard") to
bring the index back to the state before the merge-y operation has
started.  Not noticing a dirty index and starting a step in cherry-pick
means you cannot tell cleanly automerged paths from paths you had
modified in the index _before_ the step started.

And if you have a range that consists of two commits and
successfully did "cherry-pick -n" on the first one, because the
command is not committing, these cleanly merged paths will be
modified in the index.  Then the next step to pick the second commit
may conflict---after that, you lose the result of the first pick
from the index as some changes from the second step is already
intermixed with the result from the first step in the index.

So, no.  I do not think it makes sense to feed multiple commits to
"cherry-pick -n".