On Wed, Mar 23, 2016 at 5:13 PM, Junio C Hamano <gits...@pobox.com> wrote: > Stefan Beller <sbel...@google.com> writes: > >> On Tue, Mar 22, 2016 at 3:40 PM, Junio C Hamano <gits...@pobox.com> wrote: >>> Stefan Beller <sbel...@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 <sbel...@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.
I immediately thought of defaultActionset, because "default", as well as the "actionset" conveys the concept of choosing a subset of submodules to operate on. However You may mistake it as defaultActionSet, i.e. what action is set by default. Maybe we can revive the term "group" and call it submodule.defaultGroup. The defaultGroup is defined by selection of names, paths and labels. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
