Re: [PATCH v13 6/6] remote: resolve @{push} through remote.<name>.fetchRefmap

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

"D. Ben Knoble" <ben.knoble@gmail.com> writes:

>> A branch pushed to a remote set up with "git remote add
>> --limited-fetch" has no remote.<name>.fetch entry to map it
>> through, so @{push} cannot tell where it landed and fails with
>> "has no local tracking branch".
>
> I don't have the rest of the series paged in right now (esp. patches 4
> & 5 which deal with --limited-fetch), so forgive me if this comes from
> ignorance.
>
> Wouldn't the same problem happen if we applied the first 3 patches,
> then setup a repository's remote with a fetchRefmap and limited (or
> none) default fetch?

I think [4/6] and [5/6] would not change the picture, as they are
about making it easier to set remote.*.fetchRefmap configuration
from a command.  You can do exactly the same with "git config" to
set up the configuration and you will see the same thing.

> If so, that almost makes this seem like a bugfix
> for an earlier patch, and perhaps it belongs together?

Hmph, you may have a point.

I am not a heavy user of @{push} to begin with, but if the chain of
configuration through which we map the current branch to where it is
pushed to always assume remote.<remote>.fetch to exist, and does not
consult remote.<remote>.fetchRefmap, then yes, you could claim it as
a bug that is introduced by [3/6], I think.  

> It also would then be better justified in those terms, I think.

It is unclear what you exactly mean by "in those terms", but I agree
that tweaking @{push} to take the new remote.<remote>.fetchRefmap
into account is a logical part of that.