Junio C Hamano <gitster@xxxxxxxxx> writes: > 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, that's really helpful :) I'll address next steps on that thread.
