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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Stefan Beller <sbeller@xxxxxxxxxx> writes:

> On Tue, Mar 22, 2016 at 3:40 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>> Stefan Beller <sbeller@xxxxxxxxxx> 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@xxxxxxxxxx>
>>>
>>> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]