Hi Junio, Junio C Hamano wrote: > Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes: >> [...] > But we are already in agreement on this point, I think. Didn't I say: Yes, yes. I was just thinking out loud so it'll help me write a new commit message. Sorry for the noise. >> 2. In the case of multi-commit picking, there's an additional layer of >> decision making: did the conflict occur in the last commit in the >> range? > > Again, it would be the same thing. If the implementation forces that > decision, that would be a bug, no? > > My understanding is that multi-commit form of cherry-pick and revert > intended to allow two forms of "user done helping and telling the command > to continue" at any stage, be it the first, in the middle, or the last > operation in a series: > > - User resolves, adds and commits, and then tells the command to > continue. The command notices that the user has committed, and goes on > to the next task; or > > - User resolves, adds, and then tells the command to continue. The > command notices that the user has not committed, makes a commit and > goes on to the next task. Yep, this is exactly how it'll work after the series :D Thanks. -- Ram -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html