Junio C Hamano <gitster@xxxxxxxxx> writes:
> The set of submodules you "init" to the working tree are the ones
> that are interesting to you. So once the tree is populated, you do
> not ever have to look at the "defaultGroup" configuration. You just
> need to look at the working tree.
> ...
I forgot to prefix the first few paragraphs of that message with
"Here is how my version of the world should work." I did not mean
to say "Here is how you must make your work work, or I won't talk to
you." I was just hurried as I had to tend to other topics.
I actually do not care too deeply (except for the "automatically
remove" part, which I do not think we should do), as I do not think
there is a big fundamental difference between the two views. To
make sure we are on the same page, let me rephrase the two views I
have in mind.
The difference is what should happen when the user does not give any
pathspec, *label, or :name to limit the set of submodules to act on,
which, traditionally meant to work on everything, and we are trying
to change that to some "default".
(1) The default set is what the configuration file says is the
default group. The working tree state is ignored.
(2) The default set is what the configuration file says is the
default group, plus those the user showed interest by doing
"submodule init".
Suppose that the user has a mostly satisfactory default configured,
i.e. the set of submodules the configuration file says is the default
is both necessary and sufficient to carry out her daily task. Then
there is no difference between the two.
Further suppose that the user needs to view a submodule outside the
default group temporarily (imagine: for a day or two), while
carrying out some specific task. Perhaps she is working on the
documentation submodule, which is her primary task hence her
configuration file specifies it as the default, but needs to see the
submodule that houses the implementation to describe the behaviour.
So she does "init code-module/"; this has explicit pathspec, so
there is no difference between the two. Now, while reading the code
module, she finds a typo in a comment, and wants to fix it. We will
start to see differences.
* When she wants to get a bird's eye view of everything she cares
about at the moment, i.e. wants to view the state of her usual
modules plus the code-module she is visiting, (1) is more
cumbersome.
With (1), "diff --recursive" will not step outside of her
configured default, so she says "diff --recursive \*default
code-module/" to say "I want to see both my default submodule(s)
and the one I checked out by hand".
With (2), she does not have to do anything special, as manually
checked out code-module/ will be acted upon, in addition to the
configured default.
* When she wants to see her usual modules ignoring the one-off
checkout, (1) is easier.
With (1), she can say "diff --recursive" and done.
With (2), she needs to say "diff --recursive \*default" to
explicitly state "I may have checkouts of other submodules, but
this time I want to view only the usual default of mine".
The difference is not that big either case.
Whichever way we choose to make the default behaviour, the user
needs to type a bit extra when asking a behaviour that is different
from the default behaviour.
The amount of "extra" in the first use case necessary for (1) is
greater than the amount of "extra" in the second use case necessary
for (2), though. In addition, in the second use case, (1) makes it
easier for the user to miss important changes she made outside the
area of her usual attention, while (2) forces her to make a
conscious effort to exclude them. These are the reasons why I have
a slight preference for (2) over (1).
--
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