Re: [Feature request] Separate explicit fetch mapping from default fetch selection

Phillip Wood <[email protected]> writes:

>> It was a long ago this was invented, and I haven't used it for
>> almost forever, but shouldn't this
>> 
>>      $ git fetch \
>>              --refmap="refs/heads/*:refs/remotes/origin/*" \
>>              origin topic/example
>> 
>> do what you want to do?  If so, perhaps it would make a good
>> starting point to make it easier to use (e.g., perhaps a
>> configuration variable can specify the refmap to be used, or
>> something).
>
> So we'd have something like "remote.<remote>.fetchMap" and 
> "remote.<remote>.pushMap" that mapped refnames, but did not affect what 
> gets fetched or push by default? That sounds useful (I've not thought 
> through the interaction with the existing settings though).

As I said, I do not know what the final system should look like,
but the idea behind 'refmap' was to separate (A) the rule
describing the correspondence between reference names on their end
and those on our end, and (B) the specification of which source
references are transferred to the destination repository.  Since the
transfer can work both ways, we would need two sets of maps, one for
each direction.

Once established, I suspect that 'git fetch' could learn something
like the 'matching' mode that 'git push' has in 'push.default'.
Using that mode, the OP's everyday 'git fetch' would then: (1)
interact with the default remote; (2) decide which of their
references to fetch by reverse-mapping the remote-tracking branches
we already have using the fetch 'refmap'; and (3) update the
remote-tracking references using those references we decided to
fetch in the previous step.  If the OP decides to extend the area of
interest by fetching a new branch from the remote,

    $ git fetch origin a-new-topic

naming only the remote and their branch, we would know which
remote-tracking branch to store the result in and add a new
refs/remotes/origin/a-new-topic remote-tracking branch.  This would
automatically extend what the next 'git fetch' grabs from them.

Or something like that, perhaps?