Re: organizing multiple repositories with dependencies

[<dag@xxxxxxxx>]

Jens Lehmann <Jens.Lehmann@xxxxxx> 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.

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

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

> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html