Re: Joining Repositories

From: Junio C Hamano <junkio@cox.net>
Date: 2006-01-19 04:30:52
Linus Torvalds <torvalds@osdl.org> writes:

> On Wed, 18 Jan 2006, Ryan Anderson wrote:
>>
>> Assuming both repositories are clean, no extraneous files, and without
>> testing, of course:
>>
>> ... "coolest merge ever" recipe here ... 
>> 
>> No history rewritten,
>
> Right.

>> merging with the old repositories should, at least theoretically, work, 
>> etc.
>
> No. This - and the history rewriting - both have a fundamental problem: it 
> becomes totally impossible to merge back any changes of the subprojects, 
> at least automatically.

Right.

> In the "gitk" case, we could actually continue to merge stuff after a 
> join, but that was largaly because there was no renaming. That's a very 
> special case, and it also became impossible to merge back.

Correct.

> Now, let's see what Junio comes up with,...

Well, since the reason the original RFI came was "somehow we
forgot these things are together but ended up having to and need
a way to rectify the situation", in this particular case,
merging back the changes to subprojects (which is very awkward
if not impossible after a "coolest merge ever") is a non issue.

Tracking history across renames is something we have only half
of the needed support.  We can notice rename points but there is
no way to tell our usability tools to automatically follow it.
IOW "whatchanged r1/hello.c" will stop at the point the
original project renamed hello.c to r1/hello.c in preparation
for the coolest merge and you have to restart whatchanged at
that commit with "whatchanged $that_commit hello.c" to go
further back; but that is true when no project merge is involved
so it may be an issue but it is not a new issue.

So for this case, I think the "coolest merge" is the right thing
to do.

> suggest just something like
>
> 	git clone oldrepo r1
> 	cd r1
> 	git checkout -b join-branch
> 	cd ..
> 	git add r1/.git/refs/heads/join-branch
> 	git commit -m "Join repo 'oldrepo' at 'r1'"
>
> which should actually work except for the fact that we don't like the 
> ".git" component even as part of a sub-component (ie small hack to git 
> required to make it not ignore that path).

Sorry you lost me with this.  The "join-branch" is a file with
commit object name in it, so is this "recording the revision of
the other project this particular version of the project is
linked to" idea?

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Received on Thu Jan 19 04:31:19 2006

This archive was generated by hypermail 2.1.8 : 2006-01-19 04:31:37 EST