Stefan Beller <sbeller@xxxxxxxxxx> writes:
> 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.
OK, although I didn't propose anything ;-).
>
>>
>>>> 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.
I wonder if that is a valid argument. Git's position has always
been very clear after doing this:
git add -f foo.bin && echo \*.bin >>.gitignore
What the user might have said in the "configuration" is the default
suggestion, that is much weaker than what has been done to the
repository data. I think "the path is recorded in the index" in the
ignore/exclude situation is similar to "the submodule is initialized
in the working tree" in this context.
> 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.
Which "others" are mucking with your working tree? (don't respond:
I'll come to the answer a few lines below).
>
> # 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
I see. I think that is where the conceptual bug lies. Thanks for
an illustration.
If we take an approach similar to ignore/exclude, then yes the
"default" action should be done to "defaultGroup" specified plus
what the user instantiated in the working tree already. And that
is not limited to "update" operation.
Just like "git diff" is not the only thing that would show
difference in foo.bin in the working tree even when *.bin is
ignored, but we consistently treat foo.bin as tracked.
> 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.
Users want to initialize a module and keep it checked out even if
they do intend to keep it pristine and not making any changes
themselves, only so that other parts of the tree that depends on the
module can be built. So "removing a tracked and unmodified thing
from the working tree does not hurt users" is a nonsense argument,
isn't it? I would be very unhappy if "git status" removed pristine
paths from the working tree and toggle assume-unchanged bit in my
index automatically.
I am afraid you are focused too much on "version control" and losing
sight of those who use the data stored in "version control", perhaps
because you worked in submodule area too long and too hard?
--
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