Re: [RFC_PATCHv4 5/7] submodule update: respect submodule.actionOnLabel

> Stefan Beller <sbeller@google.com> writes:
>
>> On Tue, Mar 22, 2016 at 3:40 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Stefan Beller <sbeller@google.com> writes:
>>>
>>>> This change introduces the 'submodule.actionOnLabel' variable
>>>> in a repository configuration. Generally speaking 'submodule.actionOnLabel'
>>>> restricts the action of a command when no submodules are selected via the
>>>> command line explicitely to those submodules, which are selected by
>>>> 'submodule.actionOnLabel'. It can occur multiple times and can specify
>>>> the path, the name or one of the labels of a submodule to select that
>>>> submodule.
>>>>
>>>> The introduction of 'submodule.actionOnLabel' starts with
>>>> 'git submodule update' in this patch and other commands will follow
>>>> in later patches.
>>>>
>>>> 'submodule.actionOnLabel' implies '--init' in 'git submodule update'.
>>>>
>>>> Signed-off-by: Stefan Beller <sbeller@google.com>
>>>>
>>>> TODO: generic documentation for submodule.actionOnLabel
>>>> TODO: documentation for submodule update
>>>
>>> TODO: a name that matches the concept better.
>>
>> This is one of the hardest parts of the series so far. The last reviews
>> were mostly bike shedding about the name of the concept and I thought
>> we were settled to actionOnLabel as that fits best to what we want to do.
>>
>> So let's revisit that. My current understanding of the design:
>
> I am not questioning the name "label" to call the facility that
> allows projects to group submodules together, and that serves as one
> of the ways to choose what subset of submodules are worked on by
> default.  There is no need to revisit that part.
>
> What I am questioning is
>
>         action On Label
>
> because
>
>  (1) it sounds as if that configuration were a way to choose what
>      action is done to the chosen subset of submodules;
>
>  (2) it sounds as if the only way to choose a subset of submodules
>      to be operated on by default is via the "label" mechanism.
>
> And from your writing (omitted), I think we agree that we definitely
> want to avoid the misunderstanding that is (1).  This variable does
> not specify what is done--this specifies what subset of submodules
> are to be operated on.  Having "action" in the name of the variable
> is wrong.
>
> And from the proposed log message, it is clear that "label" is not
> the only way to specify the subset of submodules to be worked on,
> i.e. "... can specify the path, name or the labels".   Having
> "label" in the variable name is wrong.
>
> I am tempted to suggest submodule.defaultOperand and I am fairly
> sure "default" part of that name gets the concept much better than
> "actionOnLabel", but there probably are much better words than
> Operand.