Re: [RFC/PATCH 0/2] CHERRY_HEAD

From: Jay Soffian <jaysoffian@gmail.com>
Date: Feb 15, 2011, 22:11 UTC
Message-ID: <AANLkTinV+cY-fND2bemDGdShnfqQGMG3eUmZPXrpKayt@mail.gmail.com>
In-Reply-To: <AANLkTik2NM+mxKgZy_9dCwydz+An4sFM_a4U9mdrJBq3@mail.gmail.com>

On Tue, Feb 15, 2011 at 4:51 PM, Ævar Arnfjörð Bjarmason <avarab@gmail.com> 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.