Re: ar/submodule-udpate (was Re: What's cooking in git.git (Mar 2022, #02; Mon, 7))

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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>
>> 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'.

Sounds reasonable to me. That's similar to e.g.
ab/config-based-hooks-[1|2], which used to be es/config-based-hooks.

> How many more parts do you anticipate to have, by the way?

Just one more (thankfully) :).



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux