Re: `git fetch --refmap=<refspec>… <repository> <refspec>… ` providing NON-empty <refspec> to the --refmap ALSO causes Git to ignore the configured refspecs
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@kdbg.org> wrote:
Show 30 quoted lines
>
> 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
>
Han Jiang <jhcarl0814@gmail.com>