Glen Choo <chooglen@xxxxxxxxxx> writes: > Junio C Hamano <gitster@xxxxxxxxx> writes: > >> * ar/submodule-update (2022-03-04) 13 commits >> - submodule--helper update-clone: check for --filter and --init >> - submodule update: add tests for --filter >> - submodule--helper: remove ensure-core-worktree >> - submodule--helper update-clone: learn --init >> - submodule--helper: allow setting superprefix for init_submodule() >> - submodule--helper: refactor get_submodule_displaypath() >> - submodule--helper run-update-procedure: learn --remote >> - submodule--helper: don't use bitfield indirection for parse_options() >> - submodule--helper: get remote names from any repository >> - submodule--helper run-update-procedure: remove --suboid >> - submodule--helper: reorganize code for sh to C conversion >> - submodule--helper: remove update-module-mode >> - submodule tests: test for init and update failure output >> >> Rewrite of "git submodule update" in C (early part). >> >> Will merge to 'next'? >> source: <20220305001401.20888-1-chooglen@xxxxxxxxxx> > > I don't anticipate further comments, so I think this set of patches > should be pretty safe to merge :) No news is no indication, though ;-) As long as the previous rounds, except the parts that have been changed in this round, have been favorably reviewed, and the updates in this round have already been reviewed well, it would be good, and I think that is true for this series. > A comment on the branch name: we kept the name 'ar/submodule-update' > from when Atharva Raykar <raykar.ath@xxxxxxxxx> prepared v1 of his > series that converts all of "git submodule update" to C. When other > authors sent subsequent versions, it still made sense to keep this name > because the patches still reached the same end state of having all of > "git submodule update" in C. > > However, I've since broken this series up in two (to play better with > other topics), and the above-named patches don't do a _full_ conversion > of "git submodule update". Is something like "ar/submodule-update-1" > more appropriate? You've already taken over the ownership of the majority of patches in the series, and it may not be a bad idea to rename it to something like gc/submodule-update-part-1 before it hits 'next'. How many more parts do you anticipate to have, by the way? Thanks.
