Re: [PATCH/RFC 1/2] Add 'git subtree' command for tracking history of subtrees separately.

From: Avery Pennarun <apenwarr@gmail.com>
Date: Jul 17, 2009, 15:47 UTC
Message-ID: <32541b130907170847g67c89d54ke9426ed8da26a9aa@mail.gmail.com>
In-Reply-To: <cdea6cd10907170016u11af7230hbbee92682604530f@mail.gmail.com>

On Fri, Jul 17, 2009 at 3:16 AM, Andrey Smirnov<allter@gmail.com> wrote:

Show 15 quoted lines

> On Fri, Jul 17, 2009 at 2:27 AM, Avery Pennarun<apenwarr> wrote:
>>> 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.
>> rebase doesn't
>> have any parameters called a "target."  What does git-subtree know
>> that you don't know?
>
> By "rebase target" I mean the mutual relation of git-rebase <newbase>
> and <upstream> paramaters
> that define where will be the rebased commits. git-subtree can infer
> that NewProj contains library up to
> test-split and that OldProj contains library upto test-split-old. The
> concept of the whole git-subtee workflow
> is still blurry to me though, so I will report when I gather more
> usage statistics.

The problem is that test-split and test-split-old are completely unrelated trees that have similar-looking files but no common ancestry. All git-subtree knows is exactly that. It can't simplify anything (in your case) like you seem to think it can.

git-rebase tries to be cleverer, and starts comparing patches and file similarities so it can graft one tree onto another, and for convenience, it throws away redundant commits that do exactly what some other commit did (basically). This is actually really messy. As soon as you get into that situation, you have nothing but a mess. My advice would be to clean up the mess as soon as you can (which appropriate use of git-subtree + git-rebase can help you do).

Then you'll have actual, valid merge history, and git-subtree will be able to work smoothly using just that.

Show 8 quoted lines

>> I don't really understand what you're asking for here.
>
> At most I need generic ability to shift merged and rebased
> repository's or ref's "left" (selecting some directory or file)
> and "right" (prepending some directory to all paths) before actual
> operation(s). I.e. the antonym of 'split'
> but without 'add' committree-joining semantics. This can be
> implemented with some chaining/plumbing presets.

I think that if you're having this problem, you should look for a less ugly solution :)

What I think you're asking for is a way of turning all the commits in a subdir into a patch stream (which git-subtree split can do, essentially), but then to add a prefix to all the paths in all the patches, so that you can then apply those patches on top of some other repo where the files were in another location. You can do that, I guess, but you're not taking advantage of git's convenience.

git-subtree encourages you to think of the files in the subtree as their own separate project, and you can then merge that separate project into yours. That's actually a more accurate model of reality, I think.

Have fun,

Avery