Re: organizing multiple repositories with dependencies

From: Jens Lehmann <jens.lehmann@web.de>
Date: Apr 24, 2012, 20:26 UTC
Message-ID: <4F970C92.3030704@web.de>
In-Reply-To: <201204241759.q3OHxSbH017287@no.baka.org>

Am 24.04.2012 19:59, schrieb Seth Robertson:

Show 13 quoted lines

> 
> In message <nngbomh3uz0.fsf@transit.us.cray.com>, dag@cray.com writes:
> 
>     > I agree and am willing to provide information about submodule use cases,
>     > advantages and problems, but I'm not a user of subtree so I can't really
>     > comment on it. Now that subtree is in git core, what about putting such
>     > a comparison under Documentation/subproject-support.txt?
> 
>     That would be great.  Do you want to start work on that?  I can
>     contribute some text about git-subtree.
> 
> I have a document I created for gitslave which I have cleaned up a bit
> and might be the start of such comparison.

Thanks for providing the input. Unfortunately I'll be pretty occupied for the next three weeks, so I won't be able to put much work into that before mid-May. But maybe we can get the ball rolling ...

In the end I'd like to see a document people can use to decide what subproject support suits their needs best. Maybe it should start with the basic concept behind each of them:

submodules: A submodule is a full fledged repository of which a certain commit is recorded in a gitlink entry in each of the the superproject's commits. The emphasis lies on tightly coupling versions of both while keeping the boundaries between superproject and submodules visible. This leads to some extra cost when doing changes in a submodule but makes it easy to evaluate and select new changes from upstream and push back local changes to their respective upstream.

subtree: All subprojects become an integral part of the history of the superproject. The emphasis lies on incorporating the subtree and its history into the superproject. That adds some extra cost when it comes to pushing subtree changes back to their upstream (starting with the need for careful commit planning for local commits intended to be pushed out again) and less fine grained control over importing changes from the subtrees upstream.

gitslave: This creates a federation of full fledged git repositories which are operated on by the gits commands together (where a git command would only operate on the superproject). The emphasis lies on the simultaneous operation of gits commands on all git repositories. It does not provide any coupling of the commits in the superproject and the slave repositories (but you can use tags to have that at some points in the history).

What do you think? (Please point out anything I misrepresented in the last two paragraphs, they are based solely on what I picked up on this list and are not based on any actual experience ;-)

Then we could describe in a table what to do when to fetch new subproject commits, how to "select" them in the superproject and how to push them back to their respective upstream. Another interesting question could be how a bug in a subproject that affects the superproject is handled in each of the scenarios. Does that sound like a start?