Re: [RFC/PATCH 0/2] CHERRY_HEAD

From: Christian Couder <christian.couder@gmail.com>
Date: Feb 17, 2011, 14:09 UTC
Message-ID: <AANLkTikWX-Pzok6MZofMD_=pPSvC5iANbzKbs0wgrZ4Q@mail.gmail.com>
In-Reply-To: <AANLkTinV+cY-fND2bemDGdShnfqQGMG3eUmZPXrpKayt@mail.gmail.com>

Hi,

On Tue, Feb 15, 2011 at 11:11 PM, Jay Soffian <jaysoffian@gmail.com> wrote:

Show 21 quoted lines

> 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.

Many people wanted to be able to cherry pick many commits, so it seems logical to make cherry-pick accept a range of commits.

About the implementation, it's better if it's in C. And it's true that it would be better if rebase and cherry-pick could use the same logic and even share the same code, but that's exactly what the goal of the sequencer project has been.

I started to implement cherry-pick --continue and posted some RFC WIP patches last november:

http://thread.gmane.org/gmane.comp.version-control.git/162183/focus=162197

the goal is to have something that in the end can be reused by rebase, am and perhaps other commands.

I did some work on it after that, but I got stalled and had not much time during the last months to move it further. I will see if I can find time to work on it during the next weeks and/or publish/post the current state.

> 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?

If you are interested, perhaps you can have a look at what I posted last november. And if you want to work on it you can ask me to publish the current state, and eventually base some of your work on that.

Thanks, Christian.