On Thu, 24 Jul 2008, Avery Pennarun 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). -Daniel *This .sig left intentionally blank* -- 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