git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Christian Couder <christian.couder@gmail.com>
To: Jay Soffian <jaysoffian@gmail.com>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>, git@vger.kernel.org
Subject: Re: [RFC/PATCH 0/2] CHERRY_HEAD
Date: Thu, 17 Feb 2011 15:09:40 +0100	[thread overview]
Message-ID: <AANLkTikWX-Pzok6MZofMD_=pPSvC5iANbzKbs0wgrZ4Q@mail.gmail.com> (raw)
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:
> 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.

      parent reply	other threads:[~2011-02-17 14:10 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-15 21:23 [RFC/PATCH 0/2] CHERRY_HEAD Jay Soffian
2011-02-15 21:23 ` [RFC/PATCH 1/2] Introduce CHERRY_HEAD Jay Soffian
2011-02-15 22:13   ` Junio C Hamano
2011-02-15 22:18   ` Jonathan Nieder
2011-02-15 22:59     ` Junio C Hamano
2011-02-15 23:02       ` Bert Wesarg
2011-02-15 23:10         ` Junio C Hamano
2011-02-15 23:42           ` Bert Wesarg
2011-02-15 23:07       ` Jay Soffian
2011-02-15 23:08       ` Jonathan Nieder
2011-02-15 21:23 ` [RFC/PATCH 2/2] Teach commit to handle CHERRY_HEAD automatically Jay Soffian
2011-02-15 22:16   ` Jay Soffian
2011-02-15 22:34   ` Junio C Hamano
2011-02-15 23:00   ` Jonathan Nieder
2011-02-15 23:21     ` Jay Soffian
2011-02-15 23:47       ` Jonathan Nieder
2011-02-16  0:03         ` Jay Soffian
2011-02-16  0:08           ` Jonathan Nieder
2011-02-16  0:05         ` [PATCH] Documentation: clarify interaction of --reset-author with --author Jonathan Nieder
2011-02-16  1:04           ` Junio C Hamano
2011-02-15 21:51 ` [RFC/PATCH 0/2] CHERRY_HEAD Ævar Arnfjörð Bjarmason
2011-02-15 22:10   ` Junio C Hamano
2011-02-15 22:13     ` Jay Soffian
2011-02-15 22:30       ` Ævar Arnfjörð Bjarmason
2011-02-15 22:11   ` Jay Soffian
2011-02-16  1:48     ` Miles Bader
2011-02-17 14:09     ` Christian Couder [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='AANLkTikWX-Pzok6MZofMD_=pPSvC5iANbzKbs0wgrZ4Q@mail.gmail.com' \
    --to=christian.couder@gmail.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jaysoffian@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).