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

[Andrey Smirnov <allter@gmail.com>]

Hello!

Avery Pennarun <apenwarr> writes:

> 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.