On Wed, Apr 14, 2021 at 12:56:27PM +0200, Ævar Arnfjörð Bjarmason wrote:
> Now, what people *do actually* legitimately use this information is a
> convenient local cache of "what's the main upstream branch?".
>
> I myself have written local scripts that used that, and been bitten by
> this information being stale / not there (in the case of
> init/config/fetch).
>
> But why does anyone need that? Well, I don't think they actually
> do. What they actually do want is to push or fetch the "main"
> branch. The "what was HEAD that one time I talked to this remote" is
> just a roundabout way of getting that.
>
> So isn't this whole thing just wart that we should fix in the protocol?
> Wouldn't the use-case for this be satisfied with something like:
>
> [branch "master"]
> remote = origin
> merge = HEAD ; does not work as you might expect
>
> Right now that will just push to refs/heads/HEAD, but what if we had a
> protocol extension to intercept it (or rather, some merge = <a name
> incompatible with a current push, maybe "$HEAD">, as an aside setting it
> to ":HEAD" has some very funny results) wouldn't that satisfy the
> use-case?
Keep in mind that if we do not have a cache, then finding out the remote
HEAD involves a network trip. But we use branch.*.merge in lots of
places that aren't fetch/push. E.g., how would "git rev-parse
@{upstream}" work with the config you gave above?
> After all, who's really interested in what the remote's idea of their
> HEAD when they last fetched is?
>
> Don't those users actually want the *current* idea of what HEAD is for
> the purposes of fetching or pushing?
IMHO the cache of the remote HEAD in refs/remotes/origin/HEAD is the
same as the cache of the remote refs in refs/remotes/origin/*. We only
talk to the network during fetch/push operations, but it is convenient
to have a local cache that names the things we saw there.
As others mentioned, "git rev-parse origin" is another local command
that works without touching the network.
So I find the local cache of the remote HEAD quite useful. I think the
only issue with it is that it is not kept up to date like the rest of
the branches in refs/remotes/origin/*. That was an intentional decision,
because you may want to define your own view of what is considered the
default for the remote.
But that is a much rarer case than people who do want to auto-update it
on fetch (and for many years nobody cared too much, because people
rarely updated HEAD anyway; but these days there's quite a lot of
renaming going on). So it makes sense to at least provide a configurable
option to allow updating it on each fetch.
-Peff
