summaryrefslogtreecommitdiff
path: root/builtin/commit.c
diff options
context:
space:
mode:
authorJeff King <peff@peff.net>2025-03-08 22:10:39 -0500
committerJunio C Hamano <gitster@pobox.com>2025-03-10 13:13:45 -0700
commit095bc13f35b398b481ecd87699fea6b190488c15 (patch)
tree72dfe664467920d9757e07e2979be9b635373dac /builtin/commit.c
parent625ed92134acd8a1c8e9b795817b04189bd2a1f7 (diff)
fetch: stop protecting additions to ref-prefix list
When using the ref-prefix feature of protocol v2, a client which sends no prefixes at all will get the full advertisement. And so the code in git-fetch was historically loose about setting up that list based on our refspecs. There were cases where we needed to know about some refs, so we just didn't add anything to the ref-prefix list. And hence further code, like that for tag-following and updating origin/HEAD, had to be careful about adding to an empty list. E.g., see the bug fixed by bd52d9a058 (fetch: fix following tags when fetching specific OID, 2025-03-07). But the previous commit removed the last such case, and now we know an empty ref-prefix list (at least inside git-fetch's do_fetch() function) means that we really don't need to see any refs. So we can drop those extra conditionals. This simplifies the code a little. But it also means that some cases can now use ref prefixes when they would not otherwise. As the test shows, fetching an exact oid into a local ref can now avoid enumerating all of the refs. The refspec itself doesn't need to know about any remote refs, and the tag auto-following can just ask about refs/tags/. The same is true for asking about HEAD to update the local origin/HEAD. I didn't add a test for that yet, though, as we can optimize it even further. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'builtin/commit.c')
0 files changed, 0 insertions, 0 deletions