Re: RFC: submodule terminology

From: Junio C Hamano <junkio@cox.net>
Date: May 20, 2007, 22:59 UTC
Message-ID: <7v3b1rje45.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <200705210006.47266.johan@herland.net>

Johan Herland <johan@herland.net> writes:

Show 17 quoted lines

> 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.

> As for the low-level concept, I personally prefer "gitlink", but 
> I don't have any strong feelings.

+1