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

Glen Choo [off-list ref] writes:

Junio C Hamano [off-list ref] writes:

quoted

* 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. [off-list ref]
 source: [off-list ref]

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.

Junio C Hamano [off-list ref] writes:

Glen Choo [off-list ref] writes:

quoted

Junio C Hamano [off-list ref] writes:

quoted

* 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. [off-list ref]
 source: [off-list ref]

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.