Subject: Re: RFC: submodule terminology

From: Johan Herland <[email-masked]>
Date: Mon, 21 May 2007 01:10:01 +0200

On Monday 21 May 2007, Junio C Hamano wrote:
> Johan Herland <[email-masked]> writes:
> 
> > On Sunday 20 May 2007, Martin Waitz wrote:
> >> hoi :)
> >> 
> >> I think we should agree to one name for what currently is named
> >> submodule / subproject / dirlink / gitlink.
> >> 
> >> Or use one name for the low-level plumbing (have a tree entry
> >> which points to another commit): dirlink or gitlink and another
> >> one for the high-level UI think: submodule or subproject.
> >> But then we should use those names consequently.
> >> 
> >> Oppinions?
> >
> > For the high-level concept, "subproject" seems to me the best 
> > alternative. I think it is much better than "submodule" at 
> > describing that the subproject is a stand-alone project/repo in
> > itself.
> 
> 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.

I agree that superproject is probably the best term of all. However, 
I think it's a good idea to be explicit so as to avoid unnecessary 
confusion. My vote therefore goes to "superproject/subproject" 
rather than "superproject/project".

...Johan

-- 
Johan Herland, <[email-masked]>
www.herland.net