Re: organizing multiple repositories with dependencies

[Jens Lehmann <Jens.Lehmann@web.de>]

Am 24.04.2012 19:59, schrieb Seth Robertson:
> 
> 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?