Re: organizing multiple repositories with dependencies

From: dag@cray.com <dag@cray.com>
Date: Apr 24, 2012, 23:21 UTC
Message-ID: <nngobqg1ztl.fsf@transit.us.cray.com>
In-Reply-To: <4F970C92.3030704@web.de>

Jens Lehmann <Jens.Lehmann@web.de> writes:

[Thanks for working this! I have a few comments inlined below to hopefully help make this even better.]

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

Exactly.

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

That's far too technical. I don't even know what that means. :) I think we want to go for the average user who just wants to make an informed decision among the various models available.

> The emphasis lies on tightly coupling versions of both while keeping the
> boundaries between superproject and submodules visible.

The above is good but could use some expanding. What exactly does "tightly coupling" mean? It's kind of a generic phrase.

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

This, I think is a key differentiator for submodules and should be emphasized.

Show 8 quoted lines

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

That's a good start. I'll add some text to this later as I think there are some advantages to the approach that should be called out.

Show 8 quoted lines

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

Should gitslave be covered in this document if gitslave is not in the upstream git repository? I'm not knocking gitslave, in fact I think it's cool technology and probably _should_ be contributed upstream. I'm just asking the question about whether stuff in Documentation/ is or should be limited to things in the upstream repository.

That said, the above is good but as a user I would want more clarification on how submodules and gitslave differ. The same is true for subtrees but I'm assuming I'll handle that. :)

> 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 ;-)

It looks very good as a starting point.  Thanks!

Show 5 quoted lines

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

Yes, I was imagining exactly this sort of table.

How about creating a topic branch for this and publishing it so several of us can collaborate? I think that would make things a bit easier moving forward.

                                 -Dave