From: Avery Pennarun <apenwarr@gmail.com>
Date: Thu, 16 Jul 2009 22:27:40 GMT
Subject: Re: [PATCH/RFC 1/2] Add 'git subtree' command for tracking history of subtrees separately.
Message-ID: <32541b130907161527l1955bf06pf54b5099a5988c65@mail.gmail.com>
In-Reply-To: <cdea6cd10907161509g7771c72bl608b1924785b49fc@mail.gmail.com>

On Thu, Jul 16, 2009 at 6:09 PM, Andrey Smirnov<allter@gmail.com> wrote:
> On Thu, Jul 16, 2009 at 10:34 PM, Avery Pennarun<apenwarr> wrote:
>> I don't think that's a good idea.  git-subtree is completely separate
>> from rebasing, and doesn't deal with patches at all.  Maybe there
>> should be some kind of "force-update" option that does what "git
>> subtree add" does, but wiping out everything in the subtree before it
>> starts.  That would have simplified the above commands a bit.
>
> The only thing that links git-subtree with git-rebase is the fact, that
> git-subtree "knows" the target commit for rebases dealing with subtrees.
> So if one knows commit of a subtree that he wishes to see in superproject
> (in my case "test-split") he could issue:
>    git subtree rebase --prefix=lib OldProject test-split
>
> Though simple:
>    git rebase --onto OldProject test-split-old test-split
> worked for me, I think this was a lucky coincidence because of simplicity
> of my library commits.

I don't really understand what you're asking for here.  rebase doesn't
have any parameters called a "target."  What does git-subtree know
that you don't know?

Have fun,

Avery