Re: [PATCH/RFC v2] git-submodule: multi-level module definition

[Junio C Hamano <gitster@pobox.com>]

"Ping Yin" <pkufranky@gmail.com> writes:

>>  I would agree that allowing the user to use a short-hand to name a group
>>  of modules the user is interested in would be a good idea, but I think
>>  .gitmodules is a wrong place to do so.  The grouping is a user preference,
>>  isn't it?
>>
>>  The place the owner of the repository (not the project) expresses which
>>  modules are of interest, what transports she wants to use to access it,
>>  etc. is $GIT_DIR/config, and .gitmodules is a vehicle to supply hints to
>>  be used when the user populates that information.
>>
> Not always the case. In my company environment, we have many
> submodules and have a unified hierachy of modules,...
> ..., it's better to put the
> common config in .gitmodules to pass to every one.

I think we are saying the same thing, and I do not understand why you
sound so upset about my comments.  I never said it is bad to copy the
"hints" supplied by .gitmodules verbatim to $GIT_DIR/config.

See how the current cmd_init() uses the information in .gitmodules.  It
could later become interactive to allow users to override what's in there,
but by default it simply uses the information from .gitmodules verbatim.

In the special case of everybody using exactly the same settings, you can
have "all" submodule group alias in .gitmodules, and the user can say "git
submodule init all", which would set up the set of the modules the user
would work with, using the "hints" in the .gitmodules distributed company
wide verbatim.

One of the goal of the overall design of submodules is _not forcing_ but
still allowing such uniformity, and I think using $GIT_DIR/config as
authoritative and treating in-tree .gitmodules as hint to prime
$GIT_DIR/config is quite fundamental to that design.  Let's make sure we
do not needlessly deviate from it.

Because names to name things are fundamental part of the communication, I
do not think we would want to allow users to call A what the project as a
whole calls B.  The use of .gitmodules by the current module_name() that
maps a specific name to a path is not just fine but is preferred for this
reason (i.e. if we copied them to $GIT_DIR/config it would only introduce
tower-of-babel confusion).

However, a short-hand to name groups of submodules is not just about
naming one thing with one name, but has user convenience aspect too.
There should be per-user customizability built into the design.  You could
probably fix this by making the code first consult $GIT_DIR/config and
then fall back on in-tree .gitmodules file.

By the way, in your patch, I notice that quoting of $name is often very
loosely done.  I do not think we have officially defined what the allowed
repertoire of module name characters are, but we probably should declare
the rules and make sure the code actively enforces it to prevent future
grief.  I'd say the same restriction as we have for refnames, except
that we do not allow slashes either, is good enough?