Glen Choo <chooglen@xxxxxxxxxx> writes: > Junio C Hamano <gitster@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> >> source: <20220308001433.94995-1-chooglen@xxxxxxxxxx> > > 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.
