Re: [PATCH 11/15] diff: ignore submodules excluded by groups

From: Stefan Beller <sbeller@google.com>
Date: May 5, 2016, 22:50 UTC
Message-ID: <CAGZ79kYKbef7DTkmE3Vf3C=PLfgB3xf0ikVKHFUfQ8+KkgGHPg@mail.gmail.com>
In-Reply-To: <xmqqfutw9mfs.fsf@gitster.mtv.corp.google.com>

On Thu, May 5, 2016 at 3:20 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 53 quoted lines

> Stefan Beller <sbeller@google.com> 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.)

Show 7 quoted lines

>>     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.

Show 21 quoted lines

>
> 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.

Show 5 quoted lines

> 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?