Subject: Re: RFC: submodule terminology

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

On Monday 21 May 2007, Martin Waitz wrote:
> hoi :)
> 
> On Mon, May 21, 2007 at 12:06:47AM +0200, Johan Herland wrote:
> > 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.
> 
> it may be developed independently but for the sake of the more important
> bigger ("the top level project") it really is only one small part.
> That and the fact that "module" is already an established term
> in software makes me prefer "submodule".
> For me the project is always the top-level one: the project you
> currently work for.

"The project you currently work for" depends on your POV. But I agree
that using the term "project" alone might be confusing. That's why I'd
rather talk about "superproject" and "subproject". That way, there's
no ambiguity at all.

> > As for the low-level concept, I personally prefer "gitlink", but 
> > I don't have any strong feelings. The fact that "gitlink" seems 
> > to already be used in the code (as in resolve_gitlink_ref() etc.), 
> > coupled with "dirlink" being somewhat ambiguous (i.e. may also be 
> > interpreted as "(sym)link to directory") makes the case for me.
> 
> The only problem I have with gitlink is that there already was
> a lot of discussion about some entirely different "gitlink", so
> choosing a different name is not that bad.
> Aside from that I prefer gitlink, too.

The term "gitlink" is ambiguous/confusing? I didn't know. What's the 
other meaning of gitlink?

(Unless you're talking about gitlink as in "gitlink:git[7]" which 
appears all over our asciidoc documentation, but I don't think that 
counts...)

Have fun!

...Johan

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