Re: [PATCH 0/4] Submodule Groups

From: Sebastian Schuberth <sschuberth@gmail.com>
Date: Jan 22, 2016, 08:55 UTC
Message-ID: <CAHGBnuMRd3bg4KYito08U8LJNC3JAJFBVz-APZxVJyd6WKO6TQ@mail.gmail.com>
In-Reply-To: <CAGZ79ka+LZHRjVB8bZ4u+-n-U06mUWsbx9nRVCvd4aPwrb7yHQ@mail.gmail.com>

On Thu, Jan 21, 2016 at 10:56 PM, Stefan Beller <sbeller@google.com> wrote:

Show 10 quoted lines

>>> [submodule "gcc"]
>>>          path = gcc
>>>          url = git://...
>>>          groups = default
>>>          groups = devel
>>
>> On the quick I was unable to find the rationale why entries are now stored as separated lines compared to v1. I liked the comma-separated approach better as it's more compact.
>
> IIUC the line oriented way is preferred as it is our standard. Do we
> have any other options stored as a comma separated list?

Out of my head I cannot think of any. But that shouldn't mean we cannot introduce such comma separated list if it makes sense.

> Makes sense to use singular then. However per discussion with Junio in
> [PATCH 3/4] submodule update: Initialize all group-selected submodules
> by default, we want to not name it "group", as it's unclear what a group is
> supposed to mean. What does a group do? which operations are supported?

How about calling it "label" instead of "group"? IMO with the word "label" it's more clean that a single submodule can have multiple labels, as the concept of labels is familiar to the user already from applications like Firefox (bookmarks), Google Mail, Mac OS X Finder (files) etc.

Show 10 quoted lines

> Instead of having a submodule -> set assignment, we could do it the
> other way round:
>
>      [submodule "gcc"]
>          ...
>
>      [submodule-set "default"]
>         submodule = gcc
>         submodule = foo
>         submodule = by/path/*

In your example you're now introducing "set" as a new term. Shouldn't this better be "submodule-group" then? I actually like this idea quite a bit as it completely solves the problem about being clear that a submodule can belong to mutiple groups.

> but I'd assume this is less useful for the user. How often does a user ask:
> "How many/Which submodules are in $GROUP" as opposed to "What about
> submodule foo,
> is that part of group $GROUP?"

True, but for answering that question a user would not look at .gitmodules, but run a command, and the implementation of that command would completely hide that complexity from the user.

> As asked above, how many comma separated things do we have in git configs?
> I'd really not want to add more mental complexity to Git. As far as I

I don't think it can get much worse anyway ;-)

> remember we have
> rather double configs than one long line separated somehow.
> (The only thing that comes to mind is multiple remote urls for pushing)

I believe so, too. But I'd see the introduction of comma-separated values as an exit-strategy to that. More settings could make use of that in the future, then.

-- 
Sebastian Schuberth