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$(echo .)org \
--cc=git@vger$(echo .)kernel.org \
--cc=johan@herland$(echo .)net \
--cc=junkio@cox$(echo .)net \
--cc=ray007@gmx$(echo .)net \
--cc=tali@admingilde$(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