Hi, Christian Couder wrote: > I think that the risk at this point might be to overengineer things > and to lose time, and then we will perhaps find out that we need to do > some refactoring of the merge_recursive API anyway. I agree with the general principle... let's see if I understand the details of what you are saying. > If we have cherry-pick with --abort, --continue and --skip that just > works as well or nearly as well (because it's new) as other stuff it > will be already a very good thing. Does "other stuff" mean scripts like "git rebase"? If I understand correctly, "git rebase" updates the $dotest directory before each cherry-pick, unlike this series which only updates $dotest after a failed cherry-pick. > And with enough tests we will > hopefully be able to build and refactor safely after that. Maybe we > will eventually find out that what you suggest is in fact needed even > for cherry-pick with --abort, --continue and --skip, but for now I > would prefer trying to make it work with as few changes and work as > possible. I suspect that refactoring everything to use error() in place of die() requires more risky changes and work than updating .git/sequencer/ between cherry-picks. Of course I can easily be wrong. Hoping that is clearer, Jonathan -- 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