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