Hi,
Daniel Barkalow wrote:
> > On 7/24/08, Alex Riesen <raa.lkml@xxxxxxxxx> wrote:
> > > Avery Pennarun, Thu, Jul 24, 2008 22:16:06 +0200:
> > > > On 7/24/08, Alex Riesen <raa.lkml@xxxxxxxxx> wrote:
> > >
> > > > > gcp3 ()
> > > > > {
> > > > > git format-patch -k --stdout --full-index "$@" | git am -k -3 --binary
> > > > > }
> > > >
> > > > But that'll give up when there are conflicts, right? git-rebase lets
> > > > me fix them in a nice way.
> > >
> > > No, it same as in rebase. You'll fix them and do "git am --resolved".
> > > See manpage of git am.
> >
> > Hmm, cool.
> >
> > So that command isn't too easy to come upon by accident. If I wanted
> > to submit a patch to make this process a bit more obvious, would it
> > make sense to simply have git-cherry-pick call that sequence when you
> > give it more than one commit?
>
> Before terribly long, we'll have "git sequencer", which should be easy to
> get to do the "rebase -i" thing with cherry-pick-style usage (somebody
> would just need to write code to generate the correct series of pick
> statements).
For simple cases this code could be something like:
git rev-list --reverse --cherry-pick --no-merges --first-parent <from>..<to> |
sed 's/^/pick /' | git sequencer
(At least this is what I use relatively often.)
But as long as git sequencer is not in official git, this is not an
option. :)
Regards,
Stephan
--
Stephan Beyer <s-beyer@xxxxxxx>, PGP 0x6EDDD207FCC5040F
--
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
