Re: cherry-pick --no-commit does not work well with --continue in case of conflicts
Ilya Kantorwrites: > P.S. I assume, `cherry-pick -n ` 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".
Re: cherry-pick --no-commit does not work well with --continue in case of conflicts
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 ` 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
Ilya Kantorwrites: > 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.
cherry-pick --no-commit does not work well with --continue in case of conflicts
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