Re: [PATCH v10 1/5] fetch: add remote.<name>.refmap

[Junio C Hamano <gitster@pobox.com>]

Phillip Wood <phillip.wood123@gmail.com> writes:

> On 26/10/2026 15:48, Junio C Hamano wrote:
>> 
>> I actually do not think we should have master next seen on the same
>> remote.cabal.fetch configuration variable.  It is a multi-valued
>> variable, so it should read more like
>> 
>>           [remote "cabal"]
>>                   fetch = refs/heads/master
>>                   fetch = refs/heads/next
>>                   fetch = refs/heads/seen
>>                   refmap = +refs/heads/*:refs/remotes/cabal/*
>
> Doesn't that cause older versions of git to try and update the local 
> branch when fetching, or is it only when pushing that we'll fill in the 
> right hand side of the refspec with a copy of the left hand side?

"git fetch --help" is fairly clear on what should happen in its
description on <refspec> command line arguments, and 

I meant in the above example that remote.cabal.fetch should be used
as if these three refnames are written on the fetch command line
when nothing is given from the command line.  Now, <refspec> that
does not have :dst side for fetch stores the result nowhere but
FETCH_HEAD, so without remote.cabal.refmap (i.e., older versions of
git), you will get them in FETCH_HEAD, so your "git pull" will still
work to create an octopus merge ;-)

I was hoping that with refmap, the users can tell the system where
to store them.  As specifying a shorthand also works,

           [remote "cabal"]
                   fetch = master
                   fetch = next
                   fetch = seen
                   refmap = +refs/heads/*:refs/remotes/cabal/*

would be an easy layout to allow adding different branches than
having to say

           [remote "cabal"]
                   fetch = +refs/heads/master:refs/remotes/cabal/master
                   fetch = +refs/heads/next:refs/remotes/cabal/next
                   fetch = +refs/heads/seen:refs/remotes/cabal/seen


Thanks.