Re: [PATCH 11/15] diff: ignore submodules excluded by groups
- From
Junio C Hamano <gitster@pobox.com>
- Date
- May 5, 2016, 22:20 UTC
- Message-ID
- <xmqqfutw9mfs.fsf@gitster.mtv.corp.google.com>
- In-Reply-To
- <CAGZ79kYGbjOKPQk8A-ag+JgvybW4Kf5=g8azVAOoMq79oXc5-Q@mail.gmail.com>
Stefan Beller <sbeller@google.com> writes:
Show 10 quoted lines
> 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 ;-).
Show 13 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? > > 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).
Show 11 quoted lines
> > # 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.
Show 6 quoted lines
> 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?