On Tue, Feb 15, 2011 at 4:51 PM, Ãvar ArnfjÃrà Bjarmason <avarab@xxxxxxxxx> wrote: > I've read this over, haven't run it, but I really like the idea. It > sucks that you have to save away the commit sha1 somwhere after a > failed cherry-pick to use it again. It should just behave like `git > rebase --continue`, which this implements. I agree and I said as much. The problem is that cherry-pick has two modes of behavior: 1. Given a single commit. Historically this was the only way to use it. In this case, the behavior after a conflict should be the same as after a merge conflict. You resolve the conflicts then use git commit. 2. Given a rev-list. This is relatively recent addition to cherry-pick (7e2bfd3 revert: allow cherry-picking more than one commit, 2010-06-02). Here's where I'd expect to have a more rebase-like behavior, using --continue/abort to work through the sequence. But frankly, I consider 7e2bfd3 a mistake. I think a better implementation would be to make cherry-pick be plumbing, and re-use rebase's logic for walking through the series of commit. I'd like to do (2) eventually[*] but I think in the mean time this is a nice incremental improvement. [*] is the sequencer project dead? > It'll need some tests as a non-RFC, but otherwise it looks good. Yep, I wanted to make sure I wasn't off in the weeds first. :-) Thanks, j. -- 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