Re: [PATCH 11/15] diff: ignore submodules excluded by groups

Junio C Hamano <gitster@pobox.com> writes:

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).