Ilya Kantor <iliakan@xxxxxxxxx> 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".
