From: Glen Choo Date: Wed, 16 Mar 2022 20:54:36 GMT Subject: Re: gc/recursive-fetch-with-unused-submodules (was Re: What's cooking in git.git (Mar 2022, #03; Mon, 14)) Message-ID: In-Reply-To: Junio C Hamano writes: > Glen Choo writes: > >> Junio C Hamano 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. >>> source: <20220308001433.94995-1-chooglen@google.com> >> >> Is 'Expecting a reroll.' accurate? >> 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 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.