summaryrefslogtreecommitdiff
path: root/Documentation/gitremote-helpers.txt
diff options
context:
space:
mode:
authorLibravatar Glen Choo <chooglen@google.com>2022-03-07 16:14:32 -0800
committerLibravatar Junio C Hamano <gitster@pobox.com>2022-03-16 16:08:59 -0700
commitb90d9f7632d380d3f16197ae657ab57075acd1eb (patch)
treea89794a4a8f9add7069a79d86e1854fff540d04f /Documentation/gitremote-helpers.txt
parentsubmodule: move logic into fetch_task_create() (diff)
downloadtgif-b90d9f7632d380d3f16197ae657ab57075acd1eb.tar.xz
fetch: fetch unpopulated, changed submodules
"git fetch --recurse-submodules" only considers populated submodules (i.e. submodules that can be found by iterating the index), which makes "git fetch" behave differently based on which commit is checked out. As a result, even if the user has initialized all submodules correctly, they may not fetch the necessary submodule commits, and commands like "git checkout --recurse-submodules" might fail. Teach "git fetch" to fetch cloned, changed submodules regardless of whether they are populated. This is in addition to the current behavior of fetching populated submodules (which is always attempted regardless of what was fetched in the superproject, or even if nothing was fetched in the superproject). A submodule may be encountered multiple times (via the list of populated submodules or via the list of changed submodules). When this happens, "git fetch" only reads the 'populated copy' and ignores the 'changed copy'. Amend the verify_fetch_result() test helper so that we can assert on which 'copy' is being read. Signed-off-by: Glen Choo <chooglen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'Documentation/gitremote-helpers.txt')
0 files changed, 0 insertions, 0 deletions