On Sun, Aug 2, 2009 at 1:30 AM, Avery Pennarun<apenwarr@xxxxxxxxx> wrote:
> On Sun, Aug 2, 2009 at 2:37 AM, <skillzero@xxxxxxxxx> wrote:
>> Is it possible to use the subtree merge strategy to import just one
>> directory from a repository into a directory of a different
>> repository? The subtree merge example describes bringing in an entire
>> repository as a directory, but I'm not sure how to adapt that to just
>> import part of the source repository. The repositories are completely
>> different, but repository A has a couple directories I want to import
>> into repository B (along with the history that affected those
>> directories). I may also make changes on either side and it would be
>> nice to be able to re-merge in either direction.
>>
>> I was thinking I might need something like the git-subtree script, but
>> maybe this can be done with standard git commands?
>
> git tracks the history of the entire tree, not each subtree. So if
> you use the existing set of commit objects in A, then you'll pull in
> *all* the files of A.
>
> You have basically two choices here:
>
> 1) Merge the *entire* history of project A into project B, and during
> the merge, delete the files you don't want. (This will result in a
> repo that's about the size of A+B, even if you only keep 1% of the
> files, and every change to every file in A will now show up in B's
> history.) Merging future changes from A to B will be relatively easy
> (although you'll get conflicts on those files you deleted), but
> merging from B back to A will probably make a mess.
>
> 2) Use "git subtree split" to take the subdir of A and give it a
> history of its own, then merge that history into a subdir of B (using
> "git subtree add" or any other subtree merge method you want to use).
> You can then git subtree split/merge back and forth between A and B in
> the future to copy future changes from one to the other.
>
> The disadvantage of #2 is that git subtree ends up creating new "fake"
> commit objects for your new shared subproject. If you merge the new
> subproject back into A, you'll end up with some duplicate commit
> messages (unless you use --squash).
Thanks for the help. I tried #2 and it sort of worked. The history was
imported, but the resulting paths were flattened. Here's what I did:
>From repository 1:
git subtree split --prefix=A/B/C --rejoin
... printed commit ID 11f1ef890c49634e822a40a818a6ac88bfc50f07
>From repository 2:
git remote add -f Repo1 /path/to/repo/1
git subtree add --prefix=X/Y/C 11f1ef890c49634e822a40a818a6ac88bfc50f07
If I do 'git log X/Y/C', I only see a single commit:
Add 'X/Y/C/' from commit '11f1ef890c49634e822a40a818a6ac88bfc50f07'
git-subtree-dir: X/Y/C
git-subtree-mainline: 8b07aa647895aa8a7597dc545821bfd195ecaf7f
git-subtree-split: 11f1ef890c49634e822a40a818a6ac88bfc50f07
The full history doesn't seem to be associated with that directory. If
I do 'git log --name-only --topo-order', I see the full history, but
the files are listed as:
file.c
and I was expecting to see:
X/Y/C/file.c
Because I'd want to be able to do 'git log X/Y/C' and see all the
commits that affect that directory.
Is there a way to import such that the relative paths are retained? So
for the above example, since file.c came from A/B/C/file.c in the
original repository, I'd want it to show up in the log for
X/Y/C/file.c.
--
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