>From Jeff King, Mon 02 Mar 2020 at 08:32:17 (-0500) :
> > I think you looked at the RR_REMOTE_NAME (ref-filter.c:1455), here the
> > situation is handled by RR_REMOTE_REF, where explicit is not used at all.
> > So we could remove it.
>
> We do look at it, but it's pointless to do so:
Oh sorry, I don't know how I missed this line while I saw it above.
>
> $ git grep -hn -C4 remote_ref_for_branch origin:ref-filter.c
> 1461- } else if (atom->u.remote_ref.option == RR_REMOTE_REF) {
> 1462- int explicit;
> 1463- const char *merge;
> 1464-
> 1465: merge = remote_ref_for_branch(branch, atom->u.remote_ref.push,
> 1466- &explicit);
> 1467- *s = xstrdup(explicit ? merge : "");
> 1468- } else
> 1469- BUG("unhandled RR_* enum");
>
> I think we probably ought to do this as a preparatory patch in your
> series.
I wonder about the case of RR_REMOTE_NAME to.
We always have explicit=1, except if we fallback all the way to 'origin',
via pushremote_for_branch and then remote_for_branch. But 'origin' even
through it is implicit, is still the name of the remote we fetch/push to by
default. So should not %(push), %(upstream) still show origin in this case?
