1. If the doc says "providing an empty <refspec> to the --refmap option causes Git to ignore the configured refspecs and rely entirely on the refspecs supplied as command-line arguments" then it's reasonable to guess that "providing a non-empty <refspec> will not do those". (Otherwise the doc could just say "providing a <refspec> will do those" without the word "empty".) This is both logical fallacy and common sense. 2. Searching "empty string" "empty value" in https://git-scm.com/docs/git-config shows that using empty value to clear lower priority configurations (and non-empty values just stack up) is common behavior of multi-valued configuration variables. On Wed, Sep 4, 2024 at 6:15 PM Johannes Sixt <j6t@xxxxxxxx> wrote: > > Am 04.09.24 um 06:09 schrieb Han Jiang: > > What did you expect to happen? (Expected behavior) > > > > In `git fetch --refmap='+refs/heads/branch1:refs/remotes/server/branch1' > > server branch1 branch2`, > > `remote.server.fetch=+refs/heads/*:refs/remotes/server/*` merges with > > `--refmap='+refs/heads/branch1:refs/remotes/server/branch1'`, > > The way I read the documentation of --refmap, I cannot infer any sort of > merging of refspec, only that a replacement occurs. > > > so these should be what would be done: > > branch1 -> server/branch1 > > branch2 -> server/branch2 > > > > What happened instead? (Actual behavior) > > > > In `git fetch --refmap='+refs/heads/branch1:refs/remotes/server/branch1' > > server branch1 branch2`, > > `remote.server.fetch=+refs/heads/*:refs/remotes/server/*` is replaced > > by `--refmap='+refs/heads/branch1:refs/remotes/server/branch1'`, > > so these are what would be done: > > branch1 -> server/branch1 > > So, this seems the correct output, because it is no longer specified how > branch2 should be stored locally. > > -- Hannes >
