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

From: Junio C Hamano <gitster@pobox.com>
Date: May 5, 2016, 20:19 UTC
Message-ID: <xmqqy47o9s1h.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAGZ79ka37jWYDJrAWy5KLhaaJmrLRbmTzRC6A5DneuE63+XCeQ@mail.gmail.com>

Stefan Beller <sbeller@google.com> writes:

Show 22 quoted lines

> Any thoughts on my thoughts below?
>
>> So here is a thought experiment:
>>
>>     # get all submodules into the work tree
>>     git submodule update --recursive --init
>>
>>     # The selected default group will not include all submodules
>>     git config submodule.defaultGroup "*SomeLabel"
>>
>>     git status
>>     # What do we expect now?
>>     # either a "nothing to commit, working directory clean"
>>     # or rather what was described in 0/15:
>>
>>         More than 2 submodules (123 actually) including
>>             'path/foo'
>>             'lib/baz'
>>         are checked out, but not part of the default group.
>>         You can add these submodules via
>>             git config --add submodule.defaultGroup ./path/foo
>>             git config --add submodule.defaultGroup ./lib/baz

That may be an interesting thing to know, but I am not sure if it adds value to the user. The user wanted the defaultGroup to be the set of submodules labeled with SomeLabel, and an alternative valid suggestion could be

	'path/foo' and other submodules are not part of what you are
	interested in; if you want to deinitialize them, do

            git submodule deinit !defaultGroup

Both look equally valid to me, but offering both would be way too much. I'd say you should give that only with "status -v" or something, perhaps?

>> If we want to go with the second option,

You already lost me here, as it is not clear what two "options" you are comparing.

Show 6 quoted lines

>> If we want to go with the second option, the design described in 0/15
>> is broken. Going one step further:
>>
>> ...
>>     # But what about subC which is not in the default group? It was
>> changed as well.

So why not show it?  Is there anything controversial?

If you are truly not interested in it by excluding it from the default group, you wouldn't have touched it in the first place. If you did touch it, then you are showing some special interest that overrides what you said in the default mechanism.

In short, I think I understood what you wanted with your analogy to the ignore/exclude mechanism in 0/15. Default is a handy way to say "I do not want to bother specifying everything from the command line every time" but we can say that it is nothing more than that. That is exactly how the ignore/exclude mechanism is used--"git add" by default will not add those that are ignored when discovering paths by recursively descending, but once added, that is part of what the user told Git that she cares about.

>> In case we report these submodules which are checked out but not in
>> the default group, we probably want to adapt "git submodule update" to
>> un-checkout the work tree of the submodules in case they are clean.

Why?

Letting them know that they have such an option, and giving them a way to tell which submodules fall into that category, are both good things. But why is it a good thing to automatically clean what the user has checked out (which I expect that she expects to remain until she explicitly tells us otherwise)?

We do not automatically "git rm" a clean tracked path that happens to match .gitignore pattern and I do not think it is a good thing to do so.

Puzzled.