From: <dag@cray•com>
To: Jens Lehmann <Jens.Lehmann@web•de>
Cc: Seth Robertson <in-gitvger@baka•org>,
Hilco Wijbenga <hilco.wijbenga@gmail•com>,
Git Users <git@vger•kernel.org>,
Junio C Hamano <gitster@pobox•com>, <greened@obbligato•org>
Subject: Re: organizing multiple repositories with dependencies
Date: Tue, 24 Apr 2012 18:21:10 -0500 [thread overview]
Message-ID: <nngobqg1ztl.fsf@transit.us.cray.com> (raw)
In-Reply-To: <4F970C92.3030704@web.de> (Jens Lehmann's message of "Tue, 24 Apr 2012 22:26:58 +0200")
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.
> 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
next prev parent reply other threads:[~2012-04-24 23:21 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-16 9:27 organizing multiple repositories with dependencies Namit Bhalla
2012-04-16 14:30 ` Jakub Narebski
2012-04-16 20:08 ` dag
2012-04-17 17:29 ` Hilco Wijbenga
2012-04-17 17:51 ` dag
2012-04-17 18:37 ` Seth Robertson
2012-04-17 19:55 ` Hilco Wijbenga
2012-04-17 20:51 ` dag
2012-04-17 21:43 ` Hilco Wijbenga
2012-04-17 22:25 ` PJ Weisberg
2012-04-17 22:49 ` Hilco Wijbenga
2012-04-18 10:15 ` Namit Bhalla
2012-04-18 12:09 ` Jens Lehmann
2012-04-24 17:17 ` dag
2012-04-24 18:54 ` Hilco Wijbenga
2012-04-24 21:09 ` PJ Weisberg
2012-04-24 22:04 ` Hilco Wijbenga
2012-04-24 23:33 ` dag
2012-04-30 19:25 ` Phil Hord
2012-04-30 19:43 ` dag
2012-04-18 12:19 ` Jens Lehmann
2012-04-24 17:22 ` dag
2012-04-24 17:59 ` Seth Robertson
2012-04-24 20:26 ` Jens Lehmann
2012-04-24 20:52 ` Seth Robertson
2012-04-24 23:21 ` dag [this message]
2012-04-28 17:31 ` username localhost
2012-04-24 23:25 ` dag
2012-04-25 12:48 ` Seth Robertson
2012-04-27 14:23 ` dag
2012-04-24 19:48 ` Eugene Sajine
2012-04-24 22:11 ` Hilco Wijbenga
2012-04-24 23:38 ` dag
2012-04-24 23:36 ` dag
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=nngobqg1ztl.fsf@transit.us.cray.com \
--to=dag@cray$(echo .)com \
--cc=Jens.Lehmann@web$(echo .)de \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=greened@obbligato$(echo .)org \
--cc=hilco.wijbenga@gmail$(echo .)com \
--cc=in-gitvger@baka$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox