On Thu, May 5, 2016 at 3:20 PM, Junio C Hamano <[email protected]> wrote:
> Stefan Beller <[email protected]> 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
I think here is when the conceptual bug happens.
We would want a
git checkout --keep-submodules-to-pristine-default-group
(intentionally long bad name)
that option would init new submodules and deinit old submodules
which were clean before. Here we can compare it to a file,
i.e. after checkout some files are newly there, some are deleted.
(And that's totally expected)
If we had this `checkout --treat-submodules-as-files-for-defaultGroup`,
then the following command `git submodule update` would not be
required.
I think long term this is a far better approach.
I just wonder what the `checkout --recurse-submodules` should do when
there is no defaultGroup configured. (i.e. should that delete submodules
which were there before and delete them if they were clean? Just like files.)
>> 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.
Yes.
>
> 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.
The `submodule init` command could learn to just add that path of the
extra submodule to the defaultGroup, such that it persists between
different checkouts.
> 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.
No, `checkout` did it for you. Assume we had a "defaultGroup for files",
(others call it "narrow clones")
# in git.git
git set-file-default-group Documentation/RelNotes
git checkout v2.6.0
ls Documentation/RelNotes |grep v2.7
# no files! But this is uncontroversial as it's current behavior
# even with fictional "files default group" set to "all files ever"
ls builtin/
# does it exist? No because set-file-default-group
# did restrict out interest here.
>
> 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?
Not sure what you mean here. (Neither did I work long nor hard in that area.)
I am aware that other operations such as a build system would be glad to
have the contents of the submodules there. But those would not use a
restrictive default group?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
