Hello!
On Thu, Jul 16, 2009 at 10:34 PM, Avery Pennarun<apenwarr> wrote:
>> 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
> So, why don't they have a common root? This is, of course, the
> primary cause of your problems.
The line with OldProj and NewProj is story of commits for the project
that contains both library and other code. The line with test-split
and test-split-old is the story of commits of the shared library alone
with test-split-old corresponding to OldProj and test-split
corresponding to NewProj.
And I needed to get changes test-split-old..test-split in superproject
(but without other
garbage commits that lead to NewProj).
> How did this shared library get merged into OldProj and NewProj in the
> first place? Did you just copy the files, or did you use something
> like 'git merge -s subtree'? If the latter, you should be able to
> convince git-subtree to produce two split repositories with identical
> roots, and then merge smoothly between them.
They don't share commits because the library was never developed on its own.
The library evolved from the common code that was cut and pasted
trough about a hundred
web projects stored in SVN. Before I started to use git (mostly I use
it as merge/rebase tool
because our primary VCS is still Subversion) I transplanted changes in
library by manual
svn merge, even on individual files in some cases. While I was typing
my previous message, I
found that if I added "--rejoin", I would have situation that imitate
effect of "add test-split-old"
command followed by "merge -s subtree test-merged":
...X ----- Y ----- OldProj ----- rejoined-merge ----...---- Z ---- NewProj
/ \
X' ----- Y'==test-split-old Z''==test-merged
\
Z'==test-split
But Subversion and git-svn don't like git-ish merges, they need rebase. :(
> git checkout -b test-merged test-split
> git checkout OldProj
> git subtree split --prefix=lib OldProj --rejoin
> git subtree merge --prefix=lib test-merged
Yes, that's one of ways I thought of and that I pictured above. But I
would like
approach that deals only with patches and not commit trees due to
git-svn restriction.
>> 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.
> 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.
--
Sincerly yours, Andrey.
--
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