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

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

[Ilya Kantor]

Somewhy cherry-pick --no-commit does not work well with --continue.

Let's say I'm copying changes w/o committing and get a conflict:

> git cherry-pick -n master..feature
error: could not apply 2c11f12... Run work

Then I fix the conflict, but cherry-pick refuses to go on:

> git add .
> git cherry-pick --continue
error: your local changes would be overwritten by cherry-pick.
fatal: cherry-pick failed

It could continue *if* I committed, but I'm --no-commit for a reason,
so I shouldn't have to commit to go on with cherry-pick.

Maybe there's a preliminary check that prevents --continue and should be fixed?

---
Best Regards,
Ilya Kantor

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

[Junio C Hamano]

Ilya Kantor <iliakan@gmail.com> writes:

> Somewhy cherry-pick --no-commit does not work well with --continue.
>
> Let's say I'm copying changes w/o committing and get a conflict:
>
>> git cherry-pick -n master..feature
> error: could not apply 2c11f12... Run work
>
> Then I fix the conflict, but cherry-pick refuses to go on:
>
>> git add .
>> git cherry-pick --continue
> error: your local changes would be overwritten by cherry-pick.
> fatal: cherry-pick failed
>
> It could continue *if* I committed, but I'm --no-commit for a reason,
> so I shouldn't have to commit to go on with cherry-pick.

Of course you shouldn't have to, and cherry-pick --continue
shouldn't commit either.

Once you resolve the conflicts, there is no more things to do for
cherry-pick command, so --continue does not make any sense, I would
think, when using --no-commit.

For that matter, "cherry-pick --no-commit A..B", unless you are
absolutely sure A..B consists of only one commit (in which case you
should just be saying "cherry-pick --no-commit B" instead), makes no
sense, either.

So perhaps these are what we should be fixing?  I.e. reject
range-pick when --no-commit is given, and reject --continue when
working in --no-commit mode.

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

[Ilya Kantor]

Let's say master..feature has 2 commits: A and B.

Then `git cherry-pick -n master..feature` should pick-up A and then B
into the working directory and the index.

If applying A leads to a conflict, then it stops on A, like here:
>>> git cherry-pick -n master..feature
>> error: could not apply 2c11f12... Run work

Then I add the fix to the index, and should be able to continue on (B
is yet unpicked):

>>> git add .
>>> git cherry-pick --continue
>> error: your local changes would be overwritten by cherry-pick.
>> fatal: cherry-pick failed

Now it fails.
Expected behavior: should continue with picking B.

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?

Then we should be able to --continue in case of a conflict without committing.

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

[Junio C Hamano]

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".