On Monday 10 November 2008, Miklos Vajna wrote:
quoted text
> On Mon, Nov 10, 2008 at 09:01:15PM +0100, Johan Herland 
<johan@herland.net> wrote:
quoted text
> > Does it make sense to teach "git rebase" the -x option from "git
> > cherry-pick"? As with "git cherry-pick -x" it only makes sense to use
> > it if your rebasing from a public branch.
>
> But rebasing a public branch is always something we try to prevent. So
> basically -x would be useful only in case the user does what we asked
> not to do. ;-)

Sorry, I wasn't clear enough: I am talking about a copy-rebase, that is, the 
original public branch is unchanged, but you copy patches from it by making 
a local temporary branch that starts out in the same place and then 
rebasing it onto the other public branch where your want the patches to end 
up (followed by fast-forwarding the target branch and removing the temp 
branch). This is basically identical to cherry-picking a range of commits, 
but since "git cherry-pick" does not support cherry-picking a range of 
commits, this is the only alternative, AFAICS.

However, it would probably be a better solution to make "git cherry-pick" 
work on a commit range... (cf. the ongoing "multiple-commit cherry-pick" 
thread)


...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html