{"thread":{"id":"66334","subject":"[PATCH] [PATCH] Fix upload_pack_v2 response ordering for shallow fetch when server has uploadpack.allowRefInWant=true","startedAt":"2026-09-15T19:30:18Z","lastAt":"2026-09-17T06:20:54Z","messageCount":7,"participants":["Royce Remer","Junio C Hamano","Royce Gerard Remer"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"552765","messageId":"20260915193009.222678-1-royceremer@gmail.com","threadId":"66334","inReplyTo":null,"subject":"[PATCH] [PATCH] Fix upload_pack_v2 response ordering for shallow fetch when server has uploadpack.allowRefInWant=true","fromName":"Royce Remer","fromEmail":"royceremer@gmail.com","sentAt":"2026-09-15T19:30:09Z","receivedAt":"2026-09-15T19:30:18Z","isPatch":true,"body":"Signed-off-by: Royce Remer <royceremer@gmail.com>\n---\n t/t5703-upload-pack-ref-in-want.sh | 18 ++++++++++++++++++\n upload-pack.c                      |  2 +-\n 2 files changed, 19 insertions(+), 1 deletion(-)\n\ndiff --git a/t/t5703-upload-pack-ref-in-want.sh b/t/t5703-upload-pack-ref-in-want.sh\nindex 249137b467..9e2a090c9e 100755\n--- a/t/t5703-upload-pack-ref-in-want.sh\n+++ b/t/t5703-upload-pack-ref-in-want.sh\n@@ -295,6 +295,24 @@ test_expect_success 'fetching with wildcard that matches multiple refs' '\n \tgrep \"want-ref refs/heads/o/bar\" log\n '\n \n+test_expect_success 'shallow clone with ref-in-want' '\n+       rm -rf local &&\n+       GIT_TEST_PROTOCOL_VERSION=2 git clone --depth=1 \"file://$REPO\" local &&\n+       git -C \"$REPO\" rev-parse main >expected &&\n+       git -C local rev-parse refs/remotes/origin/main >actual &&\n+       test_cmp expected actual &&\n+       git -C local log --oneline refs/remotes/origin/main >log &&\n+       test_line_count = 1 log\n+'\n+\n+test_expect_success 'incremental shallow fetch with ref-in-want' '\n+       rm -rf local &&\n+       GIT_TEST_PROTOCOL_VERSION=2 git clone --depth=1 \"file://$REPO\" local &&\n+       GIT_TEST_PROTOCOL_VERSION=2 git -C local fetch --depth=2 origin main &&\n+       git -C local log --oneline refs/remotes/origin/main >log &&\n+       test_line_count = 2 log\n+'\n+\n REPO=\"$(pwd)/repo-ns\"\n \n test_expect_success 'setup namespaced repo' '\ndiff --git a/upload-pack.c b/upload-pack.c\nindex a52856d869..a70d237ad3 100644\n--- a/upload-pack.c\n+++ b/upload-pack.c\n@@ -1812,8 +1812,8 @@ int upload_pack_v2(struct repository *r, struct packet_reader *request)\n \t\t\t\tstate = UPLOAD_DONE;\n \t\t\tbreak;\n \t\tcase UPLOAD_SEND_PACK:\n-\t\t\tsend_wanted_ref_info(&data);\n \t\t\tsend_shallow_info(&data);\n+\t\t\tsend_wanted_ref_info(&data);\n \n \t\t\tif (data.uri_protocols.nr) {\n \t\t\t\tcreate_pack_file(&data, &data.uri_protocols);\n-- \n2.34.1\n\n"},{"id":"552767","messageId":"xmqqa4piz3pn.fsf@gitster.g","threadId":"66334","inReplyTo":"20260915193009.222678-1-royceremer@gmail.com","subject":"Re: [PATCH] [PATCH] Fix upload_pack_v2 response ordering for shallow fetch when server has uploadpack.allowRefInWant=true","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-09-15T19:58:44Z","receivedAt":"2026-09-15T19:58:48Z","isPatch":true,"body":"Royce Remer <royceremer@gmail.com> writes:\n\n> Signed-off-by: Royce Remer <royceremer@gmail.com>\n> ---\n\nThe usual way to compose a log message of this project is to\n\n - Give an observation on how the current system works in the\n   present tense (so no need to say \"Currently X is Y\", or\n   \"Previously X was Y\" to describe the state before your change;\n   just \"X is Y\" is enough), and discuss what you perceive as a\n   problem in it.\n\n - Propose a solution (optional---often, problem description\n   trivially leads to an obvious solution in reader's minds).\n\n - Give commands to somebody editing the codebase to \"make it so\",\n   instead of saying \"This commit does X\".\n\nin this order.  \n\nAlso see [[describe-changes]] and especially [[summary-section]] in\nDocumentation/SubmittingPatches.\n\nWhat is especially troubling in this partuclar patch is that its\ntitle claims that the change is a fix, but it does not explain why\nthe updated behaviour is more correct than the current code.\n\nThe implementations of \"git fetch\" and \"git clone\" that come with\ncurrently deployed versions of Git must be happily accepting what\nthe current implementation of \"git upload-pack\" gives them (the\nmissing proposed log message does not say it is broken in any way).\nIf a new version of \"git upload-pack\" suddenly swapped the order of\nthem, would it break existing \"git fetch\" and \"git clone\"?  If not,\nhow?\n\nThere may be other questions that naturally come to reviewers'\nminds, and a change given in this patch must come with enough\nexplanation to answer questions like the above.\n\nThanks.\n\n>  t/t5703-upload-pack-ref-in-want.sh | 18 ++++++++++++++++++\n>  upload-pack.c                      |  2 +-\n>  2 files changed, 19 insertions(+), 1 deletion(-)\n>\n> diff --git a/t/t5703-upload-pack-ref-in-want.sh b/t/t5703-upload-pack-ref-in-want.sh\n> index 249137b467..9e2a090c9e 100755\n> --- a/t/t5703-upload-pack-ref-in-want.sh\n> +++ b/t/t5703-upload-pack-ref-in-want.sh\n> @@ -295,6 +295,24 @@ test_expect_success 'fetching with wildcard that matches multiple refs' '\n>  \tgrep \"want-ref refs/heads/o/bar\" log\n>  '\n>  \n> +test_expect_success 'shallow clone with ref-in-want' '\n> +       rm -rf local &&\n> +       GIT_TEST_PROTOCOL_VERSION=2 git clone --depth=1 \"file://$REPO\" local &&\n> +       git -C \"$REPO\" rev-parse main >expected &&\n> +       git -C local rev-parse refs/remotes/origin/main >actual &&\n> +       test_cmp expected actual &&\n> +       git -C local log --oneline refs/remotes/origin/main >log &&\n> +       test_line_count = 1 log\n> +'\n> +\n> +test_expect_success 'incremental shallow fetch with ref-in-want' '\n> +       rm -rf local &&\n> +       GIT_TEST_PROTOCOL_VERSION=2 git clone --depth=1 \"file://$REPO\" local &&\n> +       GIT_TEST_PROTOCOL_VERSION=2 git -C local fetch --depth=2 origin main &&\n> +       git -C local log --oneline refs/remotes/origin/main >log &&\n> +       test_line_count = 2 log\n> +'\n> +\n>  REPO=\"$(pwd)/repo-ns\"\n>  \n>  test_expect_success 'setup namespaced repo' '\n> diff --git a/upload-pack.c b/upload-pack.c\n> index a52856d869..a70d237ad3 100644\n> --- a/upload-pack.c\n> +++ b/upload-pack.c\n> @@ -1812,8 +1812,8 @@ int upload_pack_v2(struct repository *r, struct packet_reader *request)\n>  \t\t\t\tstate = UPLOAD_DONE;\n>  \t\t\tbreak;\n>  \t\tcase UPLOAD_SEND_PACK:\n> -\t\t\tsend_wanted_ref_info(&data);\n>  \t\t\tsend_shallow_info(&data);\n> +\t\t\tsend_wanted_ref_info(&data);\n>  \n>  \t\t\tif (data.uri_protocols.nr) {\n>  \t\t\t\tcreate_pack_file(&data, &data.uri_protocols);\n"},{"id":"552768","messageId":"xmqq1pauz2ru.fsf@gitster.g","threadId":"66334","inReplyTo":"xmqqa4piz3pn.fsf@gitster.g","subject":"Re: [PATCH] [PATCH] Fix upload_pack_v2 response ordering for shallow fetch when server has uploadpack.allowRefInWant=true","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-09-15T20:19:01Z","receivedAt":"2026-09-15T20:19:05Z","isPatch":true,"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n>> diff --git a/upload-pack.c b/upload-pack.c\n>> index a52856d869..a70d237ad3 100644\n>> --- a/upload-pack.c\n>> +++ b/upload-pack.c\n>> @@ -1812,8 +1812,8 @@ int upload_pack_v2(struct repository *r, struct packet_reader *request)\n>>  \t\t\t\tstate = UPLOAD_DONE;\n>>  \t\t\tbreak;\n>>  \t\tcase UPLOAD_SEND_PACK:\n>> -\t\t\tsend_wanted_ref_info(&data);\n>>  \t\t\tsend_shallow_info(&data);\n>> +\t\t\tsend_wanted_ref_info(&data);\n>>  \n>>  \t\t\tif (data.uri_protocols.nr) {\n>>  \t\t\t\tcreate_pack_file(&data, &data.uri_protocols);\n\nI am merely guessing what your reasoning is, but is this meant to\nmatch this part of the code on the other side of the connection?\n\n\t\tcase FETCH_GET_PACK:\n\t\t\ttrace2_region_leave(\"fetch-pack\",\n\t\t\t\t\t    \"negotiation_v2\",\n\t\t\t\t\t    the_repository);\n\t\t\ttrace2_data_intmax(\"negotiation_v2\", the_repository,\n\t\t\t\t\t   \"total_rounds\", negotiation_round);\n\t\t\t/* Check for shallow-info section */\n\t\t\tif (process_section_header(&reader, \"shallow-info\", 1))\n\t\t\t\treceive_shallow_info(args, &reader, shallows, si);\n\n\t\t\tif (process_section_header(&reader, \"wanted-refs\", 1))\n\t\t\t\treceive_wanted_refs(&reader, sought, nr_sought);\n\n\nThese process_section_header() calls are made with the peek bit set,\nsignaling that it is OK if the packet we are about to receive is not\nthe one that is being checked, so what may happen is\n\n - upload-pack gives wanted-ref info and then shallow-info.\n\n - fetch-pack sees wanted-refs, notices that it is not shallow-info,\n   ignores it, and the next process_section_header() call does\n   notice it is wanted-refs and processes it.\n\nBut then, who consumes the shallow-info?  Does fetch-pack notices\nshallow-info that it did not expect to see and crashes?  If so, that\nis a very noteworthy thing to say in the proposed log message.  If\nit does not crash and goes on but without utilizing what was carried\nin the shallow-info packet, the resulting behaviour of fetch-pack\nwould be different from what we would expect, and if that is the\ncase, that difference is a noteworthy thing to decribe in the\nproposed log message.\n\nThanks.\n\n"},{"id":"552769","messageId":"CAH5QBqzG2BQMotUmwrzUc-m6oXE9C1LZPtRyeFQsCBbcMNppbQ@mail.gmail.com","threadId":"66334","inReplyTo":"xmqq1pauz2ru.fsf@gitster.g","subject":"Re: [PATCH] [PATCH] Fix upload_pack_v2 response ordering for shallow fetch when server has uploadpack.allowRefInWant=true","fromName":"Royce Gerard Remer","fromEmail":"royceremer@gmail.com","sentAt":"2026-09-15T21:03:33Z","receivedAt":"2026-09-15T21:03:47Z","isPatch":true,"body":"Apologies, clearly struggling with using git send-email for the first\ntime (and thank you for the reply). Here's the missing context from my\ncover:\n\nOn my fleet of git severs (running Gitea, although it just shells out\nto the git cli and uses this client verbatim), I enabled this in the\nupload-pack config:\nuploadpack.allowRefInWant=true\n\nClients performing fetches and clones all worked as normal unless they\nattempted a clone with the --depth parameter, where the client would\nget this error:\nfatal: expected 'packfile', received 'shallow-info'\n\nLooking at Documentation/gitprotocol-v2.adoc, it seems like when this\nfeature was added, the ordering was just incorrect server-side. You\nwouldn't notice unless:\n1) the server enabled the config above (I suspect it's not a heavily\nused feature in the wild)\n2) the client performed a fetch operation with --depth\n\nThat's what the new test cases in t/t5703-upload-pack-ref-in-want.sh\nare, those were written to prove the failure before the fix. I've been\nrunning this in my dev fleet of servers for a day now, trying various\ncombinations of clone, with/without --depth, and fetches with\n--unshallow-since . This is purely server-side to honor the existing\ndocumented contract when these two features are in use together.\n\n> If a new version of \"git upload-pack\" suddenly swapped the order of\nthem, would it break existing \"git fetch\" and \"git clone\"?\n\nI think this is a question about backwards-compatibility? This\ncombination of features appears to have never worked, so clients which\nwere receiving failures would no longer. If servers were previously\nconfigured to advertise allowRefInWant, clients could not have shallow\ncloned. If they did not have this feature configured, shallow clones\nwould work the same way (the ordering of packets is unchanged).\n\n\nOn Tue, Sep 15, 2026 at 1:19 PM Junio C Hamano <gitster@pobox.com> wrote:\n>\n> Junio C Hamano <gitster@pobox.com> writes:\n>\n> >> diff --git a/upload-pack.c b/upload-pack.c\n> >> index a52856d869..a70d237ad3 100644\n> >> --- a/upload-pack.c\n> >> +++ b/upload-pack.c\n> >> @@ -1812,8 +1812,8 @@ int upload_pack_v2(struct repository *r, struct packet_reader *request)\n> >>                              state = UPLOAD_DONE;\n> >>                      break;\n> >>              case UPLOAD_SEND_PACK:\n> >> -                    send_wanted_ref_info(&data);\n> >>                      send_shallow_info(&data);\n> >> +                    send_wanted_ref_info(&data);\n> >>\n> >>                      if (data.uri_protocols.nr) {\n> >>                              create_pack_file(&data, &data.uri_protocols);\n>\n> I am merely guessing what your reasoning is, but is this meant to\n> match this part of the code on the other side of the connection?\n>\n>                 case FETCH_GET_PACK:\n>                         trace2_region_leave(\"fetch-pack\",\n>                                             \"negotiation_v2\",\n>                                             the_repository);\n>                         trace2_data_intmax(\"negotiation_v2\", the_repository,\n>                                            \"total_rounds\", negotiation_round);\n>                         /* Check for shallow-info section */\n>                         if (process_section_header(&reader, \"shallow-info\", 1))\n>                                 receive_shallow_info(args, &reader, shallows, si);\n>\n>                         if (process_section_header(&reader, \"wanted-refs\", 1))\n>                                 receive_wanted_refs(&reader, sought, nr_sought);\n>\n>\n> These process_section_header() calls are made with the peek bit set,\n> signaling that it is OK if the packet we are about to receive is not\n> the one that is being checked, so what may happen is\n>\n>  - upload-pack gives wanted-ref info and then shallow-info.\n>\n>  - fetch-pack sees wanted-refs, notices that it is not shallow-info,\n>    ignores it, and the next process_section_header() call does\n>    notice it is wanted-refs and processes it.\n>\n> But then, who consumes the shallow-info?  Does fetch-pack notices\n> shallow-info that it did not expect to see and crashes?  If so, that\n> is a very noteworthy thing to say in the proposed log message.  If\n> it does not crash and goes on but without utilizing what was carried\n> in the shallow-info packet, the resulting behaviour of fetch-pack\n> would be different from what we would expect, and if that is the\n> case, that difference is a noteworthy thing to decribe in the\n> proposed log message.\n>\n> Thanks.\n>\n"},{"id":"552792","messageId":"xmqq1patxi2i.fsf@gitster.g","threadId":"66334","inReplyTo":"CAH5QBqzG2BQMotUmwrzUc-m6oXE9C1LZPtRyeFQsCBbcMNppbQ@mail.gmail.com","subject":"Re: [PATCH] [PATCH] Fix upload_pack_v2 response ordering for shallow fetch when server has uploadpack.allowRefInWant=true","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-09-16T16:43:49Z","receivedAt":"2026-09-16T16:43:53Z","isPatch":true,"body":"Royce Gerard Remer <royceremer@gmail.com> writes:\n\n> Apologies, clearly struggling with using git send-email for the first\n> time (and thank you for the reply). Here's the missing context from my\n> cover:\n>\n> On my fleet of git severs (running Gitea, although it just shells out\n> to the git cli and uses this client verbatim), I enabled this in the\n> upload-pack config:\n> uploadpack.allowRefInWant=true\n>\n> Clients performing fetches and clones all worked as normal unless they\n> attempted a clone with the --depth parameter, where the client would\n> get this error:\n> fatal: expected 'packfile', received 'shallow-info'\n>\n> Looking at Documentation/gitprotocol-v2.adoc, it seems like when this\n> feature was added, the ordering was just incorrect server-side. You\n> wouldn't notice unless:\n> 1) the server enabled the config above (I suspect it's not a heavily\n> used feature in the wild)\n> 2) the client performed a fetch operation with --depth\n>\n> That's what the new test cases in t/t5703-upload-pack-ref-in-want.sh\n> are, those were written to prove the failure before the fix. I've been\n> running this in my dev fleet of servers for a day now, trying various\n> combinations of clone, with/without --depth, and fetches with\n> --unshallow-since . This is purely server-side to honor the existing\n> documented contract when these two features are in use together.\n>\n>> If a new version of \"git upload-pack\" suddenly swapped the order of\n> them, would it break existing \"git fetch\" and \"git clone\"?\n>\n> I think this is a question about backwards-compatibility? This\n> combination of features appears to have never worked, so clients which\n> were receiving failures would no longer. If servers were previously\n> configured to advertise allowRefInWant, clients could not have shallow\n> cloned. If they did not have this feature configured, shallow clones\n> would work the same way (the ordering of packets is unchanged).\n\nYes, all of the above are good material to be distilled into an\nexcellent commit log message.  The way how the problematic packet\nsequence is produced, how the server and the client would behave and\ncause reliable breakage on the client, how recent the features\ninvolved in the bug are, and that apparently the combination are\nrarely used, which would all explain why this breakage hasn't been\nreported and diagnosed so far.\n\n\n"},{"id":"552799","messageId":"20260916203221.5265-1-royceremer@gmail.com","threadId":"66334","inReplyTo":"20260915193009.222678-1-royceremer@gmail.com","subject":"[PATCH v2] upload-pack: swap wanted-ref/shallow-info responses","fromName":"Royce Remer","fromEmail":"royceremer@gmail.com","sentAt":"2026-09-16T20:32:21Z","receivedAt":"2026-09-16T20:32:39Z","isPatch":true,"body":"When a server enables uploadpack.allowRefInWant, upload_pack_v2()\nsends wanted-ref info before shallow-info.  The fetch-pack client\nexpects shallow-info first; receiving them out of order causes it\nto exit:\n\n    fatal: expected 'packfile', received 'shallow-info'\n\nThis error condition only applies to protocol v2 clients performs\na shallow fetch (--depth) against servers with allowRefInWant\nconfigured.\n\nSwap the send order so that upload_pack_v2() sends shallow-info\nbefore wanted-ref info.  This is a server-side-only change and is\ncompatible with all existing client versions.\n\nSigned-off-by: Royce Remer <royceremer@gmail.com>\n---\n t/t5703-upload-pack-ref-in-want.sh | 18 ++++++++++++++++++\n upload-pack.c                      |  2 +-\n 2 files changed, 19 insertions(+), 1 deletion(-)\n\ndiff --git a/t/t5703-upload-pack-ref-in-want.sh b/t/t5703-upload-pack-ref-in-want.sh\nindex 249137b467..9e2a090c9e 100755\n--- a/t/t5703-upload-pack-ref-in-want.sh\n+++ b/t/t5703-upload-pack-ref-in-want.sh\n@@ -295,6 +295,24 @@ test_expect_success 'fetching with wildcard that matches multiple refs' '\n \tgrep \"want-ref refs/heads/o/bar\" log\n '\n \n+test_expect_success 'shallow clone with ref-in-want' '\n+       rm -rf local &&\n+       GIT_TEST_PROTOCOL_VERSION=2 git clone --depth=1 \"file://$REPO\" local &&\n+       git -C \"$REPO\" rev-parse main >expected &&\n+       git -C local rev-parse refs/remotes/origin/main >actual &&\n+       test_cmp expected actual &&\n+       git -C local log --oneline refs/remotes/origin/main >log &&\n+       test_line_count = 1 log\n+'\n+\n+test_expect_success 'incremental shallow fetch with ref-in-want' '\n+       rm -rf local &&\n+       GIT_TEST_PROTOCOL_VERSION=2 git clone --depth=1 \"file://$REPO\" local &&\n+       GIT_TEST_PROTOCOL_VERSION=2 git -C local fetch --depth=2 origin main &&\n+       git -C local log --oneline refs/remotes/origin/main >log &&\n+       test_line_count = 2 log\n+'\n+\n REPO=\"$(pwd)/repo-ns\"\n \n test_expect_success 'setup namespaced repo' '\ndiff --git a/upload-pack.c b/upload-pack.c\nindex a52856d869..a70d237ad3 100644\n--- a/upload-pack.c\n+++ b/upload-pack.c\n@@ -1812,8 +1812,8 @@ int upload_pack_v2(struct repository *r, struct packet_reader *request)\n \t\t\t\tstate = UPLOAD_DONE;\n \t\t\tbreak;\n \t\tcase UPLOAD_SEND_PACK:\n-\t\t\tsend_wanted_ref_info(&data);\n \t\t\tsend_shallow_info(&data);\n+\t\t\tsend_wanted_ref_info(&data);\n \n \t\t\tif (data.uri_protocols.nr) {\n \t\t\t\tcreate_pack_file(&data, &data.uri_protocols);\n\nbase-commit: e9019fcafe0040228b8631c30f97ae1adb61bcdc\n-- \n2.55.0.1.ga30d533ec0\n\n"},{"id":"552805","messageId":"xmqqa4pgv1oc.fsf@gitster.g","threadId":"66334","inReplyTo":"20260916203221.5265-1-royceremer@gmail.com","subject":"Re: [PATCH v2] upload-pack: swap wanted-ref/shallow-info responses","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-09-17T06:20:51Z","receivedAt":"2026-09-17T06:20:54Z","isPatch":true,"body":"Royce Remer <royceremer@gmail.com> writes:\n\n> When a server enables uploadpack.allowRefInWant, upload_pack_v2()\n> sends wanted-ref info before shallow-info.  The fetch-pack client\n> expects shallow-info first; receiving them out of order causes it\n> to exit:\n>\n>     fatal: expected 'packfile', received 'shallow-info'\n>\n> This error condition only applies to protocol v2 clients performs\n> a shallow fetch (--depth) against servers with allowRefInWant\n> configured.\n>\n> Swap the send order so that upload_pack_v2() sends shallow-info\n> before wanted-ref info.  This is a server-side-only change and is\n> compatible with all existing client versions.\n\n\nIt seems that this bug existed in the very first set of patches that\nintroduced the ref-in-want feature, namely, 733020517a (fetch-pack:\nimplement ref-in-want, 2018-06-27) and 516e2b76bd (upload-pack:\nimplement ref-in-want, 2018-06-27).  There were a few changes on the\ncode around that area, but on-the-wire protocol never changed, so it\nnever worked correctly, but the ref-in-want feature is a rather\nexotic thing to want in the first place, so it is not all that\nunexpected.\n\n>\n> Signed-off-by: Royce Remer <royceremer@gmail.com>\n> ---\n>  t/t5703-upload-pack-ref-in-want.sh | 18 ++++++++++++++++++\n>  upload-pack.c                      |  2 +-\n>  2 files changed, 19 insertions(+), 1 deletion(-)\n>\n> diff --git a/t/t5703-upload-pack-ref-in-want.sh b/t/t5703-upload-pack-ref-in-want.sh\n> index 249137b467..9e2a090c9e 100755\n> --- a/t/t5703-upload-pack-ref-in-want.sh\n> +++ b/t/t5703-upload-pack-ref-in-want.sh\n> @@ -295,6 +295,24 @@ test_expect_success 'fetching with wildcard that matches multiple refs' '\n>  \tgrep \"want-ref refs/heads/o/bar\" log\n>  '\n>  \n> +test_expect_success 'shallow clone with ref-in-want' '\n> +       rm -rf local &&\n> +       GIT_TEST_PROTOCOL_VERSION=2 git clone --depth=1 \"file://$REPO\" local &&\n> +       git -C \"$REPO\" rev-parse main >expected &&\n> +       git -C local rev-parse refs/remotes/origin/main >actual &&\n> +       test_cmp expected actual &&\n> +       git -C local log --oneline refs/remotes/origin/main >log &&\n> +       test_line_count = 1 log\n> +'\n> +\n> +test_expect_success 'incremental shallow fetch with ref-in-want' '\n> +       rm -rf local &&\n> +       GIT_TEST_PROTOCOL_VERSION=2 git clone --depth=1 \"file://$REPO\" local &&\n> +       GIT_TEST_PROTOCOL_VERSION=2 git -C local fetch --depth=2 origin main &&\n> +       git -C local log --oneline refs/remotes/origin/main >log &&\n> +       test_line_count = 2 log\n> +'\n> +\n>  REPO=\"$(pwd)/repo-ns\"\n>  \n>  test_expect_success 'setup namespaced repo' '\n> diff --git a/upload-pack.c b/upload-pack.c\n> index a52856d869..a70d237ad3 100644\n> --- a/upload-pack.c\n> +++ b/upload-pack.c\n> @@ -1812,8 +1812,8 @@ int upload_pack_v2(struct repository *r, struct packet_reader *request)\n>  \t\t\t\tstate = UPLOAD_DONE;\n>  \t\t\tbreak;\n>  \t\tcase UPLOAD_SEND_PACK:\n> -\t\t\tsend_wanted_ref_info(&data);\n>  \t\t\tsend_shallow_info(&data);\n> +\t\t\tsend_wanted_ref_info(&data);\n>  \n>  \t\t\tif (data.uri_protocols.nr) {\n>  \t\t\t\tcreate_pack_file(&data, &data.uri_protocols);\n>\n> base-commit: e9019fcafe0040228b8631c30f97ae1adb61bcdc\n"}]}