On Thu, May 5, 2016 at 11:08 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> 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.
Ok, maybe we can leave that automatically remove part out for the
first series. (Eventually submodules should behave like files and we
delete files on checkout all the time, and it's a reasonable default)
So I think to reduce scope to only cover the clone/update first, all
other operations behave like today, i.e.
git clone --recurse-submodules --init-submodule=label
--init-submodule=label2 git://...
# will clone the superproject and recursively
# checkout any submodule being labeled label or label2
git config submodule.defaultGroups default
git config --add submodule.defaultGroups devel
# configure which submodules you are interested in.
git submodule add --label <name> git://... ..
# record a label while adding a submodule
git submodule update --init-labeled(=*label)
# will update all initialized submodules
# and learn a new switch to also initialize the grouped
# submodules (either the specified group or if none given
# the default group as configured before)
git status
git diff
git submodule summary
# care about all initialized submodules, i.e. (2) below
# a switch for recurse=label will be in a later series.
>
> 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.
Another way (3) is to add code-module/ to the "set of interesting
submodules, i.e. to the default group"
git config --all submodule.defaultGroup ./code-module
git submodule update
>
> * 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.
In (3), diff --recursive will also just work fine.
>
>
> * When she wants to see her usual modules ignoring the one-off
> checkout, (1) is easier.
In (3) you'd do
git config --unset submodule.defaultGroup ./code-module
# optionally: git submodule update
>
> 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".
and diff --recursive works fine again as well.
>
> 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).
>
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.
*
--
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