Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes: > This series preserves the old workflow: > > $ git cherry-pick foo > ... conflict ... > $ echo "resolved" >problematicfile > $ git add problematicfile > $ git commit > > $ git cherry-pick foo..bar > ... conflict ... > $ echo "resolved" >problematicfile > $ git add problematicfile > $ git commit > $ git revert --continue # No, there are no typos Hmm, doesn't "git add && git cherry-pick --continue" (i.e. no "git commit" in between) trigger the "commit the resolution first and then go on"? > And introduces a brand new workflow: > > $ git cherry-pick foo > ... conflict ... > $ echo "resolved" >problematicfile > $ git add problematicfile > $ git sequencer --continue > > $ git cherry-pick foo..bar > ... conflict ... > $ echo "resolved" >problematicfile > $ git add problematicfile > $ git sequencer --continue > > $ git revert moo..baz > ... conflict ... > $ echo "resolved" >problematicfile > $ git add problematicfile > $ git sequencer --continue Almost. If these are replaced with "git cherry-pick --continue" and "git revert --continue" that internally triggers "git sequencer --continue" *and* errors out if a wrong command was used to "--continue", it would be perfect. The longer-term ultimate goal would be to make it "git continue" that covers more than the sequencer based workflow, i.e. allow "git merge" that conflicted to be concluded with "edit && git add && git continue". -- 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