Re: [PATCH v3 05/10] submodule: decouple url and submodule existence

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 14, 2017, 21:38 UTC
Message-ID: <xmqqlgs7h737.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <xmqqzignittf.fsf@gitster.mtv.corp.google.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 14 quoted lines

> Also submodule.active that takes pathspec and not name is an oddball
> (use of "name" not "path" is to prepare for a submodule whose
> location in the superproject changes depending on the commit in the
> superproject), and we need to justify with an explanation.  I think
> you envision two cases.  1. we encourage projects to adopt a
> convention that submodules are grouped with leading directory, so
> that pathspec e.g. lib/, would cover _all_ library-ish modules to
> allow those who are interested in library-ish modules to set
> ".active = lib/" just once to say any and all modules in lib/ are
> interesting.  2. another convention the projects can adopt, when
> pathspec-attribute feature is invented, is to label submodules with
> attribute to group them, so that a broad pathspec with attribute
> requirement, e.g. .:(attr:lib), can be used to say any and all
> modules with 'lib' attribute are interesting.

One addition to the point 2. above is that because .gitattributes, just like .gitmodules, is tracked by the superproject, and when a submodule that moves in the superproject tree, the project can adjust which path gets the attribute in .gitattributes, just like it can adjust which path has the submodule in .gitmodules. That makes a broad pathspec with attribute requirement just as a viable solution to identify a submodule as having an unchanging "name" for a submodule in the .gitmodules file.

> The above two points (justifications, intended uses and future
> plans) need to be clarified around here (and possibly in the
> documentation), I would think.