Re: [PATCH v6 0/4] fetch: avoid fetching every branch of a new remote in a shallow repo
flat view
From: Harald Nordgren <hidden>
Date: 2026-10-04 19:51:40
If you try to run this with [1/4] alone, however, it errors out with "fatal: --refmap option is only meaningful with command-line refspec", which is suboptimal when triggered by a configuration variable. Even though our design says that remote.*.refmap makes the command behave as if the user gave '--refmap' on the command line, applying that rule here is a bit too strict.
Thanks for pointing that out. How did you find that?
Then there is the last part, where the desired behavior is unclear. What should happen if the remote.origin.* configuration defines both fetch and refmap? How would we explain our choice to the users? I do not have a good answer to this design question.
I think that when both `remote.<name>.fetch` and `remote.<name>.refmap` are configured, remote.<name>.fetch can win.
quoted hunk ↗ jump to hunk
+test_expect_success 'remote.<name>.refmap without tracking (baseline)' ' + test_when_finished "rm -fr fetch-refmap-baseline" && + git init fetch-refmap-baseline && + ( + cd fetch-refmap-baseline && + git remote add origin ../ && + + # without fetch refspec, but with fetch refmap + git config --unset-all remote.origin.fetch && + git config remote.origin.refmap "+refs/heads/*:refs/remotes/origin/*" && + + # nothing tracked, nothing fetched, no error + git fetch origin 2>error && + test_grep ! "fatal: --refmap option is only meaningful" error && + git for-each-ref --format="%(refname)" refs/remotes/ >actual && + test_line_count = 0 actual && + + # nothing tracked, explicit ref on the command line + git fetch origin main && + git for-each-ref --format="%(refname)" refs/remotes/ >actual && + echo refs/remotes/origin/main >expect && + test_cmp expect actual && + + # what should happen when we have both refmap and refspec? + git config remote.origin.fetch "+refs/heads/*:refs/remotes/origin/*" && + git fetch origin + )
Thanks for providing this! Harald