Stefan Beller <sbeller@xxxxxxxxxx> 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 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.
--
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