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

> Stefan Beller <sbeller@google.com> writes:
>
>> 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.

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