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

From: Andrey Smirnov <allter@gmail.com>
Date: Jul 16, 2009, 18:04 UTC
Message-ID: <loom.20090716T160021-218@post.gmane.org>
In-Reply-To: <32541b130904300732i691800f5kecc2f845584071c1@mail.gmail.com>

Hello!

Avery Pennarun <apenwarr> writes:

Show 5 quoted lines

> d) Merge upstream changes of shared module:
>       git subtree pull --prefix=shared-dir shared-remote master
>     or
>       git fetch shared-remote master
>       git subtree merge --prefix=shared-dir FETCH_HEAD

I found the git-subtree aproach of handling sub-repositories very interesting and useful to me. This is the previous-to-last feature I've awaited from DVCS world since I went into it. <remark> The remaining feature I wish that's not already there is the ability to automatically track the tree of repos I work with and manage this tree as simple as filemanager-style clients like Tortoise SVN allow. This is a feature like submodules, but with tracking refs, remotes and remote URIs in a repo itself rather than in .git dirs and with different commands for propagation and display of changesets). Hope someone has time to try this approach (or at least patience to discuss). </remark>

I've just used git-subtree (latest github version) and it worked for me. However I've encountered some difficulty using it for my purpose and wish to shere the solution I've come to and ask if it is ok:

My goal was to rebase changes to shared library of two similar projects from one project to another. The commits in the more recent project were touching both lib/ directory with shared library and the rest of the project.

When I did 
   git subtree split --prefix=lib NewProj -b test-split
 and
   git subtree split --prefix=lib OldProj -b test-split-old
I got the following two trees without a common root:

...X ----- Y ----- OldProj ----...---- Z ---- NewProj

X' ----- Y'==test-split-old ----- Z'==test-split

Problem:

When I did
   git subtree merge test-split --prefix=lib
it printed:
 Auto-merged lib/x.cgi
 CONFLICT (add/add): Merge conflict in lib/x.cgi
 Auto-merged lib/y.cgi
 CONFLICT (add/add): Merge conflict in lib/y.cgi
 Automatic merge failed; fix conflicts and then commit the result.

It's obvious that it should be that way because logically both trees don't have the same root at the time of merge. But I've expected subtree merge --prefix will understand that X' is identical to changes to 'lib/*' in X, Y' to Y and Z' to Z.

Solution:

    git rebase --onto OldProj test-split-old test-split
it printed:
 First, rewinding head to replay your work on top of it...
 Applying ZZZZZ
 error: x.cgi: does not exist in index
 error: y.cgi: does not exist in index
 Using index info to reconstruct a base tree...
 Falling back to patching base and 3-way merge...

I don't know what magic it used but it did rebase right. Furthermore "-s
subtree" didn't work at all:
    git rebase --onto OldProj test-split-old test-split -s subtree
 First, rewinding head to replay your work on top of it...
 Fast-forwarded OldProj to OldProj.

And so I ask if this behavior is the way git-subtree was meant to work. It probably has sense to add 'rebase' command to git-subtree script to let perform such tasks simplier.

My best regards, Andrey Smirnov.