Re: Joining Repositories
- From
Junio C Hamano <junkio@cox.net>
- Date
- Jan 19, 2006, 02:12 UTC
- Message-ID
- <7v64ohotjj.fsf@assigned-by-dhcp.cox.net>
- In-Reply-To
- <7vbqy9xx2r.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
Show 8 quoted lines
> Linus Torvalds <torvalds@osdl.org> writes: > >> Now, let's see what Junio comes up with,... > > Well, since the reason the original RFI came was... > ... > So for this case, I think the "coolest merge" is the right > thing to do.
I said this only because I wanted to recommend a solution available today to the original requester.
If I were to talk about (one potential) future solution, I would say "bind" commit would work naturally for this case, without disrupting the development histories of the projects being combined. After all, the "bind" commit approach is not much different from what you did with "the coolest merge ever", with a few twists, such as (1) not overlaying but requiring each subproject to be bound at a non-overlapping subdirectory, and (2) letting a subproject keep its own independent history that does not know about other subprojects even after combination happens (as opposed to the coolest merge, after which there is no git history that does not have gitk as its part).
Of course, "gitlink" would equally work well and have similar characteristics. The implementation details will certainly differ and the user interaction may somewhat be different as well, but I do not think of any reason either approach would not work well in this situation.
So would Cogito subprojects support (will it be in the 0.17?), but it might look less powerful when compared with the "bind" or "gitlink", if it comes in the form of the patch Pasky sent to the list, since it does not attempt to tie the versions of two projects together. Certainly that makes it the easiest to use and understand what is going on, though.