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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html