HI again, Ramkumar Ramachandra writes: > One final resort: Move some code back into cherry-pick, and call into > a later-function in the sequencer only if it's a many-commit > operation. The new commands can enjoy the comfort of calling into an > earlier-function in the sequencer that'll do all the revision walk > setup and call the later-function. I think this is reasonable. Er, no. This would be amazingly ugly too: we'd need two versions of everything like '--continue'. And look at this glaring inconsistency: git cherry-pick foo..bar ..conflict.. git sequencer --abort $? = 0 But: git cherry-pick foo ..conflict.. git sequencer --abort error: No sequencer operation in progress. In a nutshell, the problem we're facing: We persist part of the continuation data outside the sequencer's knowledge, and part of it inside. For backward compatibility, we can't move the former part into the sequencer. -- 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