| Message ID | cover.1597722941.git.jonathantanmy@google.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Lazy fetch with subprocess | expand |
Jonathan Tan <jonathantanmy@google.com> writes: > These patches are based on jc/no-update-fetch-head, once again. FWIW, that topic no longer exists (it has been swallowed by Derrick's maintenance topics). As that topic is not near 'next' yet, we might want to kick the patch out of it into a separate jc/no-update-fetch-head topic again, base this series and also maintenance topics on top of it. > 2: 00ad7dd875 = 2: 9f277f1631 fetch: allow refspecs specified through stdin > 3: 8b4a522a13 ! 3: fda9f834f6 fetch: avoid reading submodule config until needed > @@ Metadata > ## Commit message ## > fetch: avoid reading submodule config until needed > > - Teach "git fetch" to avoid reading the submodule config until necessary. > - This allows users to avoid the lazy-fetching of this potentially missing > - config file by specifying the --recurse-submodules=no command line > - option. > + In "fetch", there are two parameters submodule_fetch_jobs_config and > + recurse_submodules that can be set in a variety of ways: through > + .gitmodules, through .git/config, and through the command line. > + Currently "fetch" handles this by first reading .gitmodules, then > + reading .git/config (allowing it to overwrite existing values), then > + reading the command line (allowing it to overwrite existing values). > + > + Notice that we can avoid reading .gitmodules if .git/config and/or the > + command line already provides us with what we need. In addition, if > + recurse_submodules is found to be "no", we do not need the value of > + submodule_fetch_jobs_config. > + > + Avoiding reading .gitmodules is especially important when we use "git > + fetch" to perform lazy fetches in a partial clone because the > + .gitmodules file itself might need to be lazy fetched (and otherwise > + causing an infinite loop). > + > + In light of all this, avoid reading .gitmodules until necessary. When > + reading it, we may only need one of the two parameters it provides, so > + teach fetch_config_from_gitmodules() to support NULL arguments. With > + this patch, users (including Git itself when invoking "git fetch" to > + lazy-fetch) will be able to guarantee avoiding reading .gitmodules by > + passing --recurse-submodules=no. Quite sensible. > 4: 77bc83e7f2 ! 4: a5554cd27f fetch: only populate existing_refs if needed > @@ Metadata > ## Commit message ## > fetch: only populate existing_refs if needed > > - When fetching tags, Git only writes tags that do not already exist in > - the client repository. This necessitates an iteration over all the refs, > - but fetch performs this iteration even if no tags are fetched. > + In "fetch", get_ref_map() iterates over all refs to populate > + "existing_refs" in order to populate peer_ref->old_oid in the returned > + refmap, even if the refmap has no peer_ref set - which is the case when > + only literal hashes (i.e. no refs by name) are fetched. Much better---the previous round gave us a wrong impression that the change is about the behaviour when fetching tags, but the updated explanation makes it clear that the primary use case is to avoid tag-following while directly fetching objects by names, not via refs.
Junio C Hamano <gitster@pobox.com> writes: > Jonathan Tan <jonathantanmy@google.com> writes: > >> These patches are based on jc/no-update-fetch-head, once again. > > FWIW, that topic no longer exists (it has been swallowed by > Derrick's maintenance topics). As that topic is not near 'next' > yet, we might want to kick the patch out of it into a separate > jc/no-update-fetch-head topic again, base this series and also > maintenance topics on top of it. So, I've recreated jc/no-update-fetch-head on top of 'master' and then rebased these patches on top (which required some adjustment due to argv-array -> strvec API rename). t5300 stops passing at "[6/7] promisor-remote: lazy-fetch", which I haven't looked into details, but the topic is queued near the tip of 'seen' for today's integration cycle. Thanks.