Stefan Beller <sbeller@xxxxxxxxxx> writes: >> 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. > > Another way (3) is to add code-module/ to the "set of interesting > submodules, i.e. to the default group" I do not want to force her to do more than "submodule deinit" when she is done with that temporary task that required her to have code-module/ checked out, which is what you are doing with such a change. So that is a non-starter to me. >> 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). >> > > That makes sense. > > So with (2) > * there is no need to modify status, diff, log for the default case and the > --recursive \*default" may come later, so the initial series can be smaller. > * I sense a premature "Send" button here ;-) In any case, I care much more about the "making it harder to miss things outside the usual area of attention" benefit than "the user may have to type less more often" benefit, even though both are slightly in favor between (1) and (2). -- 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