From: "Shawn O. Pearce" <spearce@spearce.org>
To: Raimund Bauer <ray007@gmx.net>
Cc: Junio C Hamano <junkio@cox.net>,
Johan Herland <johan@herland.net>,
git@vger.kernel.org, Martin Waitz <tali@admingilde.org>
Subject: Re: RFC: submodule terminology
Date: Mon, 21 May 2007 02:52:34 -0400 [thread overview]
Message-ID: <20070521065234.GM3141@spearce.org> (raw)
In-Reply-To: <1179729886.6187.15.camel@localhost>
Raimund Bauer <ray007@gmx.net> wrote:
> On Sun, 2007-05-20 at 15:59 -0700, Junio C Hamano wrote:
> > I was wondering if we can get away by just calling them
> > "projects", "projects containd in the superproject", etc., as I
> > tend to agree with Linus, who used the term "superproject
> > support" in his talk, that this is not really about creating
> > "subproject" which are somehow different from ordinary projects,
> > but more about supporting superprojects that can contain/point
> > at other projects, which we did not have before 1.5.2 happened.
>
> The "super" or "sub" only comes from where in a hierarchy it is used.
> Somewhere in the middle of the hierarchy it would be both?
Yes. Of course.
> I'd have said a repository can have many "modules" or "projects", and
> each of those can have several branches. A module can hold other
> modules, but from its POV also be part of a super-module (or
> superproject), we just have to take care to not build loops.
You cannot build a loop. OK, let me rephrase:
I can build a loop where at one point in time project A uses project
B as his subproject; then later I can have project B use project
A as a subproject. That's a loop. But the commits themselves are
not in a cycle. There is a specific version of A that requires a
specific version of B, and there is a different version of B that
requires an entirely different version of A.
This loop really just means we have to be smart about how we switch
between versions of a project. Just like if B is required in one
version of superproject A and not in another; when I switch back
and forth in A I expect B to appear/disappear. And I expect it
to work on an airplane, where network access to reclone B is not
available (or is too costly). That means we have to "hide" B when
its not needed.
If you can actually form a loop where version of A requires version
of B and version of B requires the version of A that requires the
version of B... that's a SHA-1 hash collision. If you can make
them at will, you probably can make some good money illegally...
> Is my view of the world correct so far?
Yes.
--
Shawn.
next prev parent reply other threads:[~2007-05-21 6:52 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-20 21:44 RFC: submodule terminology Martin Waitz
2007-05-20 22:06 ` Johan Herland
2007-05-20 22:59 ` Junio C Hamano
2007-05-20 23:10 ` Johan Herland
2007-05-21 6:44 ` Raimund Bauer
2007-05-21 6:52 ` Shawn O. Pearce [this message]
2007-05-20 23:03 ` Martin Waitz
2007-05-20 23:16 ` Johan Herland
2007-05-20 23:39 ` Martin Waitz
2007-05-21 0:32 ` Eric Lesh
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=20070521065234.GM3141@spearce.org \
--to=spearce@spearce.org \
--cc=git@vger.kernel.org \
--cc=johan@herland.net \
--cc=junkio@cox.net \
--cc=ray007@gmx.net \
--cc=tali@admingilde.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.