Re: RFC: submodule terminology

From: Johan Herland <johan@herland.net>
Date: May 20, 2007, 23:10 UTC
Message-ID: <200705210110.01223.johan@herland.net>
In-Reply-To: <7v3b1rje45.fsf@assigned-by-dhcp.cox.net>

On Monday 21 May 2007, Junio C Hamano wrote:

Show 27 quoted lines

> Johan Herland <johan@herland.net> 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, <johan@herland.net>
www.herland.net