Re: gc/recursive-fetch-with-unused-submodules (was Re: What's cooking in git.git (Mar 2022, #03; Mon, 14))

[Glen Choo <chooglen@google.com>]

Junio C Hamano <gitster@pobox.com> writes:

> Glen Choo <chooglen@google.com> writes:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> * gc/recursive-fetch-with-unused-submodules (2022-03-07) 10 commits
>>>  - submodule: fix latent check_has_commit() bug
>>>  - fetch: fetch unpopulated, changed submodules
>>>  - submodule: move logic into fetch_task_create()
>>>  - submodule: extract get_fetch_task()
>>>  - submodule: store new submodule commits oid_array in a struct
>>>  - submodule: inline submodule_commits() into caller
>>>  - submodule: make static functions read submodules from commits
>>>  - t5526: create superproject commits with test helper
>>>  - t5526: stop asserting on stderr literally
>>>  - t5526: introduce test helper to assert on fetches
>>>
>>>  When "git fetch --recurse-submodules" grabbed submodule commits
>>>  that would be needed to recursively check out newly fetched commits
>>>  in the superproject, it only paid attention to submodules that are
>>>  in the current checkout of the superproject.  We now do so for all
>>>  submodules that have been run "git submodule init" on.
>>>
>>>  Expecting a reroll.
>>>  cf. <kl6ly21p2q00.fsf@chooglen-macbookpro.roam.corp.google.com>
>>>  source: <20220308001433.94995-1-chooglen@google.com>
>>
>> Is 'Expecting a reroll.' accurate? <xmqqr17dp8s9.fsf@gitster.g>
>> indicated that this topic would be queued.
>
> "Queuing" is just that.  It may stay there for a while and be
> dropped unless it sees a decent progress (if it is expected to be
> further worked on).  That's vastly different from merging down to
> 'next'.
>
> I just re-read the message with "will queue" in it, and I only said
> the changes listed as updates from v4 looked all sensible, which
> does not mean the changes listed there are sufficient to correct all
> problems we may already had in v3.
>
> Downthread in <xmqq4k46nae4.fsf@gitster.g> and its response, I see
> we agree that "reading .gitmodules in a particular superproject
> commit is just as wrong as reading from the working tree---it should
> not be necessary to fetch in the submodule, and the API to get the
> necessary parameter to run fetch in the submodule should be cleaned
> up" and that "fixing that API can be left outside the scope of this
> topic for the sake of expediency".  I would at least expect the two
> decisions are described in an updated log message of relevant steps.

Thanks, that's really helpful :)
I'll address next steps on that thread.