Re: [PATCH 1/1] remote.c: fix handling of push:remote_ref

From: Damien Robert <damien.olivier.robert@gmail.com>
Date: Mar 3, 2020, 16:16 UTC
Message-ID: <20200303161606.xe5iof6hz2nubc7t@feanor>
In-Reply-To: <20200302133217.GA1176622@coredump.intra.peff.net>

From Jeff King, Mon 02 Mar 2020 at 08:32:17 (-0500) :

Show 5 quoted lines

> > 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.

Show 14 quoted lines

> 
>   $ 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?