{"thread":{"id":"62055","subject":"`git fetch --refmap=… …​` providing NON-empty to the --refmap ALSO causes Git to ignore the configured refspecs","startedAt":"2024-09-04T04:10:03Z","lastAt":"2024-09-04T23:52:44Z","messageCount":8,"participants":["Han Jiang","Johannes Sixt","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"502086","messageId":"CANrWfmSe0ekbRR9VsX8jALWQQVdhDv-2WTSm47jHTiV9-Z7-pg@mail.gmail.com","threadId":"62055","inReplyTo":null,"subject":"`git fetch --refmap=… …​` providing NON-empty to the --refmap ALSO causes Git to ignore the configured refspecs","fromName":"Han Jiang","fromEmail":"jhcarl0814@gmail.com","sentAt":"2024-09-04T04:09:51Z","receivedAt":"2024-09-04T04:10:03Z","isPatch":false,"sender":{"key":"jhcarl0814@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5171262?v=4"},"body":"Thank you for filling out a Git bug report!\nPlease answer the following questions to help us understand your issue.\n\nWhat did you do before the bug happened? (Steps to reproduce your issue)\n\ncd '/'; cd '/'; rm --force --recursive -- './test_git'; mkdir \"$_\"; cd \"$_\";\nmkdir --parents -- './server' './client';\ngit -C './server' init --bare './repo.git'\ngit --git-dir='./server/repo.git' --work-tree='.' commit --allow-empty\n-m \"$((++number))\"\ngit -C './server/repo.git' branch branch1; git -C './server/repo.git'\nbranch branch2\n\ngit -C './client' init './repo'\ngit -C './client/repo' remote add server 'file://'\"$(realpath\n'./server/repo.git')\"\ngit -C './client/repo' remote --verbose\ngit -C './client/repo' config list --local --show-scope --show-origin\ngit -C './client/repo' fetch --dry-run\ngit -C './client/repo' fetch --dry-run\n--refmap='+refs/heads/*:refs/remotes/server/*' server branch1 branch2\ngit -C './client/repo' fetch --dry-run\n--refmap='+refs/heads/branch*:refs/remotes/server/branch*' server\nbranch1 branch2\ngit -C './client/repo' fetch --dry-run\n--refmap='+refs/heads/branch1:refs/remotes/server/branch1' server\nbranch1 branch2\ngit -C './client/repo' fetch\n--refmap='+refs/heads/branch1:refs/remotes/server/branch1' server\nbranch1 branch2\ngit -C './client/repo' branch --list --all --verbose --verbose\n\nWhat did you expect to happen? (Expected behavior)\n\nIn `git fetch --refmap='+refs/heads/branch1:refs/remotes/server/branch1'\nserver branch1 branch2`,\n`remote.server.fetch=+refs/heads/*:refs/remotes/server/*` merges with\n`--refmap='+refs/heads/branch1:refs/remotes/server/branch1'`,\nso these should be what would be done:\nbranch1 -> server/branch1\nbranch2 -> server/branch2\n\nWhat happened instead? (Actual behavior)\n\nIn `git fetch --refmap='+refs/heads/branch1:refs/remotes/server/branch1'\nserver branch1 branch2`,\n`remote.server.fetch=+refs/heads/*:refs/remotes/server/*` is replaced\nby `--refmap='+refs/heads/branch1:refs/remotes/server/branch1'`,\nso these are what would be done:\nbranch1 -> server/branch1\n\nWhat's different between what you expected and what actually happened?\n\nAnything else you want to add:\n\nPlease review the rest of the bug report below.\nYou can delete any lines you don't wish to share.\n\n\n[System Info]\ngit version:\ngit version 2.46.0.windows.1\ncpu: x86_64\nbuilt from commit: 2e6a859ffc0471f60f79c1256f766042b0d5d17d\nsizeof-long: 4\nsizeof-size_t: 8\nshell-path: D:/git-sdk-64-build-installers/usr/bin/sh\nfeature: fsmonitor--daemon\nlibcurl: 8.9.0\nOpenSSL: OpenSSL 3.2.2 4 Jun 2024\nzlib: 1.3.1\nuname: Windows 10.0 22631\ncompiler info: gnuc: 14.1\nlibc info: no libc information available\n$SHELL (typically, interactive shell): C:\\Program Files\\Git\\usr\\bin\\bash.exe\n\n\n[Enabled Hooks]\nnot run from a git repository - no hooks to show\n"},{"id":"502088","messageId":"a33a73f7-e6dd-4f97-a635-c6c5dfcadeb1@kdbg.org","threadId":"62055","inReplyTo":"CANrWfmSe0ekbRR9VsX8jALWQQVdhDv-2WTSm47jHTiV9-Z7-pg@mail.gmail.com","subject":"Re: `git fetch --refmap=… … ` providing NON-empty to the --refmap ALSO causes Git to ignore the configured refspecs","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2024-09-04T06:15:44Z","receivedAt":"2024-09-04T06:16:02Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 04.09.24 um 06:09 schrieb Han Jiang:\n> What did you expect to happen? (Expected behavior)\n> \n> In `git fetch --refmap='+refs/heads/branch1:refs/remotes/server/branch1'\n> server branch1 branch2`,\n> `remote.server.fetch=+refs/heads/*:refs/remotes/server/*` merges with\n> `--refmap='+refs/heads/branch1:refs/remotes/server/branch1'`,\n\nThe way I read the documentation of --refmap, I cannot infer any sort of\nmerging of refspec, only that a replacement occurs.\n\n> so these should be what would be done:\n> branch1 -> server/branch1\n> branch2 -> server/branch2\n> \n> What happened instead? (Actual behavior)\n> \n> In `git fetch --refmap='+refs/heads/branch1:refs/remotes/server/branch1'\n> server branch1 branch2`,\n> `remote.server.fetch=+refs/heads/*:refs/remotes/server/*` is replaced\n> by `--refmap='+refs/heads/branch1:refs/remotes/server/branch1'`,\n> so these are what would be done:\n> branch1 -> server/branch1\n\nSo, this seems the correct output, because it is no longer specified how\nbranch2 should be stored locally.\n\n-- Hannes\n\n"},{"id":"502109","messageId":"CANrWfmRdz1Xxud=f0GWrc=nURV2xZU8Wm=8u2X+W4tL4d-yeTg@mail.gmail.com","threadId":"62055","inReplyTo":"a33a73f7-e6dd-4f97-a635-c6c5dfcadeb1@kdbg.org","subject":"Re: `git fetch --refmap=… … ` providing NON-empty to the --refmap ALSO causes Git to ignore the configured refspecs","fromName":"Han Jiang","fromEmail":"jhcarl0814@gmail.com","sentAt":"2024-09-04T11:12:39Z","receivedAt":"2024-09-04T11:12:52Z","isPatch":false,"sender":{"key":"jhcarl0814@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5171262?v=4"},"body":"1. If the doc says \"providing an empty to the --refmap\noption causes Git to ignore the configured refspecs and rely entirely\non the refspecs supplied as command-line arguments\" then it's\nreasonable to guess that \"providing a non-empty will not do\nthose\". (Otherwise the doc could just say \"providing a will\ndo those\" without the word \"empty\".) This is both logical fallacy and\ncommon sense.\n2. Searching \"empty string\" \"empty value\" in\nhttps://git-scm.com/docs/git-config shows that using empty value to\nclear lower priority configurations (and non-empty values just stack\nup) is common behavior of multi-valued configuration variables.\n\nOn Wed, Sep 4, 2024 at 6:15 PM Johannes Sixt wrote:\n>\n> Am 04.09.24 um 06:09 schrieb Han Jiang:\n> > What did you expect to happen? (Expected behavior)\n> >\n> > In `git fetch --refmap='+refs/heads/branch1:refs/remotes/server/branch1'\n> > server branch1 branch2`,\n> > `remote.server.fetch=+refs/heads/*:refs/remotes/server/*` merges with\n> > `--refmap='+refs/heads/branch1:refs/remotes/server/branch1'`,\n>\n> The way I read the documentation of --refmap, I cannot infer any sort of\n> merging of refspec, only that a replacement occurs.\n>\n> > so these should be what would be done:\n> > branch1 -> server/branch1\n> > branch2 -> server/branch2\n> >\n> > What happened instead? (Actual behavior)\n> >\n> > In `git fetch --refmap='+refs/heads/branch1:refs/remotes/server/branch1'\n> > server branch1 branch2`,\n> > `remote.server.fetch=+refs/heads/*:refs/remotes/server/*` is replaced\n> > by `--refmap='+refs/heads/branch1:refs/remotes/server/branch1'`,\n> > so these are what would be done:\n> > branch1 -> server/branch1\n>\n> So, this seems the correct output, because it is no longer specified how\n> branch2 should be stored locally.\n>\n> -- Hannes\n>\n"},{"id":"502133","messageId":"xmqqle07ebcj.fsf@gitster.g","threadId":"62055","inReplyTo":"CANrWfmSe0ekbRR9VsX8jALWQQVdhDv-2WTSm47jHTiV9-Z7-pg@mail.gmail.com","subject":"Re: `git fetch --refmap=… …​` providing NON-empty to the --refmap ALSO causes Git to ignore the configured refspecs","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-09-04T14:34:52Z","receivedAt":"2024-09-04T14:34:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Han Jiang writes:\n\n> What happened instead? (Actual behavior)\n>\n> In `git fetch --refmap='+refs/heads/branch1:refs/remotes/server/branch1'\n> server branch1 branch2`,\n> `remote.server.fetch=+refs/heads/*:refs/remotes/server/*` is replaced\n> by `--refmap='+refs/heads/branch1:refs/remotes/server/branch1'`,\n> so these are what would be done:\n> branch1 -> server/branch1\n\nThis is totally expected.\n\nA refspec specifies \"what to fetch\" and \"where to store locally what\nwe fetched\" at the same time. A refmap only specifies the \"where\nthe stuff is stored locally\" part, and what to fetch is specified\nseparately. You asked branch1 and branch2 to be fetched (peek into\nthe .git/FETCH_HEAD file to see both objects are fetched) from the\ncommand line arguments, and your refmap specified where to store\nwhat you got from their refs/heads/branch1. As the refmap does not\nsay anything about any other branches, they are not stored anywhere\nin your local refs/ namespace.\n\nTypically --refmap is given with a glob, but the story is the same\nthere. If you fetched refs/notes/commits from that same server with\na refmap to map \"refs/heads/*:refs/remotes/server/*\", the notes commit\nis not mapped to anywhere with the refmap, so nothing will happen to\nit.\n\n\n"},{"id":"502152","messageId":"562614e4-5384-4220-896a-20b3f79771bd@kdbg.org","threadId":"62055","inReplyTo":"CANrWfmRdz1Xxud=f0GWrc=nURV2xZU8Wm=8u2X+W4tL4d-yeTg@mail.gmail.com","subject":"Re: `git fetch --refmap=… … ` providing NON-empty to the --refmap ALSO causes Git to ignore the configured refspecs","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2024-09-04T16:38:04Z","receivedAt":"2024-09-04T16:38:09Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 04.09.24 um 13:12 schrieb Han Jiang:\n> 1. If the doc says \"providing an empty to the --refmap\n> option causes Git to ignore the configured refspecs and rely entirely\n> on the refspecs supplied as command-line arguments\" then it's\n> reasonable to guess that \"providing a non-empty will not do\n> those\".\n\nFair enough. But then in section \"Configured Remote-tracking Branches\"\nit is said that \"The latter use of the remote..fetch values\ncan be overridden by giving the --refmap= parameter(s) on the\ncommand line.\" So... I dunno. Just my 2c.\n\n-- Hannes\n\n"},{"id":"502153","messageId":"xmqq5xrbbc36.fsf@gitster.g","threadId":"62055","inReplyTo":"562614e4-5384-4220-896a-20b3f79771bd@kdbg.org","subject":"Re: `git fetch --refmap=… … ` providing NON-empty to the --refmap ALSO causes Git to ignore the configured refspecs","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-09-04T16:47:09Z","receivedAt":"2024-09-04T16:47:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> Am 04.09.24 um 13:12 schrieb Han Jiang:\n>> 1. If the doc says \"providing an empty to the --refmap\n>> option causes Git to ignore the configured refspecs and rely entirely\n>> on the refspecs supplied as command-line arguments\" then it's\n>> reasonable to guess that \"providing a non-empty will not do\n>> those\".\n>\n> Fair enough. But then in section \"Configured Remote-tracking Branches\"\n> it is said that \"The latter use of the remote..fetch values\n> can be overridden by giving the --refmap= parameter(s) on the\n> command line.\" So... I dunno. Just my 2c.\n\nThis cuts both ways, I suspect. It is so unusual to say\n\n git fetch --refmap=\"\" foo bar baz\n\nto use an empty string as in \"--refmap=\", simply\nbecause you would not say\n\n git fetch origin \"\"\n\nand expect the empty string is a in \"git fetch origin \".\n\nAny string other than an empty string, e.g. \n\n git fetch --refmap=\"refs/heads/*:refs/prefetch/x/*\" foo bar baz\n\nwould have an extra side effect of storing what gets fetched, when\nyour primary focus is \"I want the command to ignore the configured\nrefspec\".\n\nFor these reasons, I would actually say it is quite fair for the\ndocumentation to single out the empty string case as an idiom that\nmay be hard for readers to figure out for themselves without being\ntold.\n\nI would not be opposed to add a sentence or two to clarify what\nhappens when a non-empty is used, though.\n\nThanks.\n\n"},{"id":"502184","messageId":"CANrWfmQXVpbZpSKjhq-2Mfbr1G0gbom+mBPgoFMxfjJKLEe5gw@mail.gmail.com","threadId":"62055","inReplyTo":"xmqqle07ebcj.fsf@gitster.g","subject":"Re: `git fetch --refmap=… …​` providing NON-empty to the --refmap ALSO causes Git to ignore the configured refspecs","fromName":"Han Jiang","fromEmail":"jhcarl0814@gmail.com","sentAt":"2024-09-04T23:41:26Z","receivedAt":"2024-09-04T23:41:38Z","isPatch":false,"sender":{"key":"jhcarl0814@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5171262?v=4"},"body":"@Junio C Hamano Thank you for the explanation!\nAs you said, \"refmap only specifies the where the stuff is stored\nlocally\" (what to fetch is specified by last command line arguments),\nbut the issue with this report is a bit complicated because it's about\nwhether \"only refmap specifies the where the stuff is stored locally\".\nAfter I search \"empty value\" or \"empty string\" in\nhttps://git-scm.com/docs/git-config , the most intuitive behavior of\n`git fetch --refmap` (for me) is:\n`git fetch ...` uses `remote..fetch`;\n`git fetch --refmap= --refmap= ...`\nuses `remote..fetch` and all the `--refmap=`s;\n`git fetch --refmap='' --refmap= --refmap= \n...` uses all the `--refmap=`s;\nI'll post an example of all of these being used at the same time to both of you.\n\nOn Thu, Sep 5, 2024 at 2:34 AM Junio C Hamano wrote:\n>\n> Han Jiang writes:\n>\n> > What happened instead? (Actual behavior)\n> >\n> > In `git fetch --refmap='+refs/heads/branch1:refs/remotes/server/branch1'\n> > server branch1 branch2`,\n> > `remote.server.fetch=+refs/heads/*:refs/remotes/server/*` is replaced\n> > by `--refmap='+refs/heads/branch1:refs/remotes/server/branch1'`,\n> > so these are what would be done:\n> > branch1 -> server/branch1\n>\n> This is totally expected.\n>\n> A refspec specifies \"what to fetch\" and \"where to store locally what\n> we fetched\" at the same time. A refmap only specifies the \"where\n> the stuff is stored locally\" part, and what to fetch is specified\n> separately. You asked branch1 and branch2 to be fetched (peek into\n> the .git/FETCH_HEAD file to see both objects are fetched) from the\n> command line arguments, and your refmap specified where to store\n> what you got from their refs/heads/branch1. As the refmap does not\n> say anything about any other branches, they are not stored anywhere\n> in your local refs/ namespace.\n>\n> Typically --refmap is given with a glob, but the story is the same\n> there. If you fetched refs/notes/commits from that same server with\n> a refmap to map \"refs/heads/*:refs/remotes/server/*\", the notes commit\n> is not mapped to anywhere with the refmap, so nothing will happen to\n> it.\n>\n>\n"},{"id":"502185","messageId":"CANrWfmQCBwjzydyBFJ5OTE7E7EJFFmht-Qz54hin0UZd1LKXCQ@mail.gmail.com","threadId":"62055","inReplyTo":"xmqq5xrbbc36.fsf@gitster.g","subject":"Re: `git fetch --refmap=… … ` providing NON-empty to the --refmap ALSO causes Git to ignore the configured refspecs","fromName":"Han Jiang","fromEmail":"jhcarl0814@gmail.com","sentAt":"2024-09-04T23:52:31Z","receivedAt":"2024-09-04T23:52:44Z","isPatch":false,"sender":{"key":"jhcarl0814@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5171262?v=4"},"body":"> But then in section \"Configured Remote-tracking Branches\" it is said that\nThe problem with the doc is \"how to override\". From\nhttps://git-scm.com/docs/git-fetch#Documentation/git-fetch.txt---refmapltrefspecgt\nit seems we need to `git fetch --refmap='' --refmap=` to\nreally override configuration variables.\nI guess the inner working is like this: first for-loop traverses\nconfiguration variable `remote..fetch` collecting s\ninto a list, then second for-loop traverses `--refmap=`s,\nclears the list when an empty string is encountered, appends to the\nlist when a non-empty string is encountered. Maybe I'm just\ndaydreaming...\n\n> git fetch --refmap=\"\" foo bar baz\nI think the correct use case of empty string, is to specify more\n--refmap=s after it (like in\nhttps://git-scm.com/docs/git-config#Documentation/git-config.txt-pushpushOption\n), otherwise the mapping (to operate upon foo,bar and baz) would be\nempty.\n\nSorry that I didn't use examples to express my intended use scenarios clearly!\n\nAfter I searched \"empty value\" or \"empty string\" in\nhttps://git-scm.com/docs/git-config yesterday, the most intuitive\nbehavior of `git fetch --refmap` (for me) was:\n`git fetch ...` uses `remote..fetch`;\n`git fetch --refmap= --refmap= ...`\nuses `remote..fetch` and all the `--refmap=`s;\n`git fetch --refmap='' --refmap= --refmap= \n...` uses all the `--refmap=`s;\n\nHere is an example of all of these being used at the same time.\n1. Normally, user uses `fetch-safe` which uses `git fetch\n--refmap=` to use whatever mappings specified by\n`remote..fetch` and also let our backup logic sneak in.\n2. Occasionally, upstream is rebased and our backup logic (refspec\nwithout `+`) blocks the process because of `--atomic`.\n2.1. When that happens, user uses `fetch-bak-current-time` which uses\n`git fetch --refmap='' --refmap=` to clear whatever mappings\nspecified by `remote..fetch` and use our another backup logic\n(refspec with `+`).\n2.2. After old tips are saved, user uses `git fetch --force` to use\nwhatever mappings specified by `remote..fetch`;\n\nCurrently [1.] is not working because --refmap=\nclears `remote..fetch` instead of merging with it. Hence this\nbug report.\n\ncd '/'; cd '/'; rm --force --recursive -- './test_git2'; mkdir \"$_\"; cd \"$_\";\nmkdir --parents -- './server' './client';\n\ngit -C './server' init --bare './repo.git'\ngit --git-dir='./server/repo.git' --work-tree='.' commit --allow-empty\n-m \"$((++number))\"\ngit --git-dir='./server/repo.git' --work-tree='.' commit --allow-empty\n-m \"$((++number))\"\ngit -C './server/repo.git' branch branch1; git -C './server/repo.git'\nbranch branch2\n\ngit -C './client' init './repo'\ngit -C './client/repo' config set --local 'alias.fetch-safe'\n'!git_fetch_safe(){ server=\"$1\"; shift; git fetch --atomic\n--refmap='\\''refs/*:refs/namespaces/'\\''\"$server\"'\\''_backup/refs/*'\\''\n\"$server\" \"$@\"; };git_fetch_safe'\ngit -C './client/repo' config set --local\n'alias.fetch-bak-current-time' '!git_fetch_bak_current_time(){\nserver=\"$1\"; shift; git -c\n'\\''remote.'\\''\"$server\"'\\''_backup.url=.'\\''\n--namespace=\"$server\"'\\''_backup'\\'' fetch\n--refmap='\\''refs/*:refs/namespaces/'\\''\"$server\"'\\''_backup_'\\''\"$(date\n+'%Y%m%d%H%M%S')\"'\\''/refs/*'\\'' \"$server\"'_backup' \"$@\"; git fetch\n--atomic --refmap='\\'\\''\n--refmap='\\''+refs/*:refs/namespaces/'\\''\"$server\"'\\''_backup/refs/*'\\''\n\"$server\" \"$@\"; };git_fetch_bak_current_time'\ngit -C './client/repo' remote add server 'file://'\"$(realpath\n'./server/repo.git')\"\ngit -C './client/repo' remote --verbose\ngit -C './client/repo' config list --local --show-scope --show-origin\ngit -C './client/repo' fetch-safe server branch1 branch2\ngit -C './client/repo' show-ref\ngit -C './client/repo' lg --all --decorate-refs='*'\n\ngit --git-dir='./server/repo.git' --work-tree='.' commit --allow-empty\n-m \"$((++number))\"\ngit -C './server/repo.git' branch --force branch1; git -C\n'./server/repo.git' branch --force branch2\ngit -C './client/repo' fetch-safe server branch1 branch2\ngit -C './client/repo' show-ref\ngit -C './client/repo' lg --all --decorate-refs='*'\n\ngit --git-dir='./server/repo.git' --work-tree='.' commit --allow-empty\n-m \"$((++number))\" --amend\ngit -C './server/repo.git' branch --force branch1; git -C\n'./server/repo.git' branch --force branch2\ngit -C './client/repo' fetch-safe server branch1 branch2\ngit -C './client/repo' show-ref\ngit -C './client/repo' lg --all --decorate-refs='*'\ngit -C './client/repo' fetch-bak-current-time server branch1 branch2\ngit -C './client/repo' show-ref\ngit -C './client/repo' lg --all --decorate-refs='*'\ngit -C './client/repo' fetch --force server branch1 branch2\ngit -C './client/repo' show-ref\ngit -C './client/repo' lg --all --decorate-refs='*'\n\nOn Thu, Sep 5, 2024 at 4:47 AM Junio C Hamano wrote:\n>\n> Johannes Sixt writes:\n>\n> > Am 04.09.24 um 13:12 schrieb Han Jiang:\n> >> 1. If the doc says \"providing an empty to the --refmap\n> >> option causes Git to ignore the configured refspecs and rely entirely\n> >> on the refspecs supplied as command-line arguments\" then it's\n> >> reasonable to guess that \"providing a non-empty will not do\n> >> those\".\n> >\n> > Fair enough. But then in section \"Configured Remote-tracking Branches\"\n> > it is said that \"The latter use of the remote..fetch values\n> > can be overridden by giving the --refmap= parameter(s) on the\n> > command line.\" So... I dunno. Just my 2c.\n>\n> This cuts both ways, I suspect. It is so unusual to say\n>\n> git fetch --refmap=\"\" foo bar baz\n>\n> to use an empty string as in \"--refmap=\", simply\n> because you would not say\n>\n> git fetch origin \"\"\n>\n> and expect the empty string is a in \"git fetch origin \".\n>\n> Any string other than an empty string, e.g.\n>\n> git fetch --refmap=\"refs/heads/*:refs/prefetch/x/*\" foo bar baz\n>\n> would have an extra side effect of storing what gets fetched, when\n> your primary focus is \"I want the command to ignore the configured\n> refspec\".\n>\n> For these reasons, I would actually say it is quite fair for the\n> documentation to single out the empty string case as an idiom that\n> may be hard for readers to figure out for themselves without being\n> told.\n>\n> I would not be opposed to add a sentence or two to clarify what\n> happens when a non-empty is used, though.\n>\n> Thanks.\n>\n"}]}