Re: Joining Repositories

From: Junio C Hamano <junkio@cox.net>
Date: Jan 18, 2006, 17:30 UTC
Message-ID: <7vbqy9xx2r.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0601180813170.3240@g5.osdl.org>

Linus Torvalds <torvalds@osdl.org> writes:

Show 10 quoted lines

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

Show 6 quoted lines

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

Show 12 quoted lines

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