On Wed, Feb 10, 2010 at 09:37:10PM +0100, Sverre Rabbelier wrote: > At the moment git cherry-pick stands out from the sequencer tools in > that it doesn't support --continue but requires you to manually supply > the '-c ...' argument to 'git commit' when there's a conflict instead. > Is it desirable that we add such an option? And if so, how would one > go about implementing it? I think it makes sense. It is perhaps a little iffy to use "continue" when you are not really continuing on to further cherry-picks (and in a rebase, continue is not just about resolving conflicts, but about continuing to the next item in the rebase). Cherry-picks are more like "am --resolved"[1]. But semantic nitpicks aside, I think "continue" is a good enough name. The differences between what it means for each command are fairly obvious based on the command, and there is real value in a user just having to remember one verb. -Peff [1] On the other hand, I usually mistype that as "git am --continue", which _does_ make sense, since you are applying a sequence of patches. Maybe "am" should support both. -- 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