On Tue, Feb 15 2022, Glen Choo wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: > >>> This seems to heavily conflict with "clone, submodule: pass partial >>> clone filters to submodules, 2022-02-04" by Josh Steadmon >>> <690d2316ad518ea4551821b2b3aa652996858475.1644034886.git.steadmon@xxxxxxxxxx> >>> in both builtins/submodule--helper.c and git-submodule.sh. >>> >>> It also removes the code that "submodule: record superproject gitdir >>> during 'update', 2022-02-03" by Emily Shaffer >>> <20220203215914.683922-5-emilyshaffer@xxxxxxxxxx>, so what the other >>> topic ends up adding to the shell script needs to eventually be >>> redone in the C code. >>> >>> I think "superproject aware" topic would see a reroll due to a >>> slight redesign. I am not sure how solid the design of the >>> "pass down partial clone filter" topic is at this moment. > > Hm, I haven't looked at where the conflicts are yet, but I'll get to it > as I'm reviewing the rest of the feedback. To save you some time, my v4 CL summarizes the semantic conflict between the two: https://lore.kernel.org/git/cover-v4-0.7-00000000000-20220127T143552Z-avarab@xxxxxxxxx/ I.e. Atharva Raykar had working C code to do what an older version of that superproject config series was doing, but the semantics changed in a later version. It needs some new usage of path.c (or similar) API adjusted, but I didn't (and still don't) have time to look into it. > [...] >> I can merge this to seen minus the above two topics and get it >> compile, but it also seems to have some interaction with 961b130d >> (branch: add --recurse-submodules option for branch creation, >> 2022-01-28) and makes the t3207, tests added by that other topic, >> fail X-<. > > Oof, that's embarrassing of me, let me take a look at that. There's a > nontrivial chance that the "branch --recurse-submodules" tests caught an > actual regression. FWIW one thing I did as an extra sanity check was to run the whole test suite with --tee with/without this series (or rather, my earlier version), and diffing the full test-results output (which you'll need to save in-between the two runs, and IIRC hack t/Makefile to stop removing it on successful runs). There's a lot of differences in output due to general issues in the test suite output not being reproducable (writing timestamps etc.), but I could not find any issues with the "git submodule" output being different, of course we may not have tests, or it may be piped to /dev/null.... But I've found it to be a helpful additional validation technique for this series & others where I'm not as confident in the test coverage.
