gc/recursive-fetch-with-unused-submodules (was Re: What's cooking in git.git (Mar 2022, #03; Mon, 14))

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

 



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.



[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