On Thu, May 5, 2016 at 1:19 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Stefan Beller <sbel...@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.
The first option is giving nothing:
git config submodule.defaultGroup "*SomeLabel"
git -C submodule-not-labeled reset --hard HEAD^
git status
# all good, no report about submodule-not-labeled
# because it is not in the default group.
# (This is implemented in the series)
The "second option" is some sort of reporting. Either what I or you proposed.
>
>>> 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?
The user made clear to not be interested in subC by setting
up the default group.
>
> 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.
Well it can get out of sync by not touching it as well, because others
changed the submodule pointer who are interested in that though.
# in the superproject
git checkout new-version
git submodule update
# checks out submodules to their version
git checkout some-ancient-version
git submodule update
# this would only update the submodules in the defaultGroup,
# not those which are initialized but "uninteresting"
# the labeling may have changed between the different versions
git status
# I don't want to see any submodule changes here.
# but there may be a submodule which is not at the right version
# as `git submodule update` only paid attention to the default group.
> 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.
git rm changes the index (which may show up in the next commit)
The state of a submodule (un-initialized, initialized, checked out)
doesn't change the index or anything. Only the working tree is affected.
And by flipping between the initialized and checked-out state we do not
lose any information (such as user configured remote urls) nor does it
affect the "state" (index, recorded tree, history) of the repository.
So I just wonder if
git init <submodule group spec>
git deinit ! <submodule group spec>
should be done in `git submodule update <submodule group spec>`
(or by having the default group configured and running `git submodule update`
with no arguments.)
>
> Puzzled.
>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
