git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Chris Torek <chris.torek@gmail.com>
Cc: Sam Bostock <sam.bostock@shopify.com>, Git List <git@vger.kernel.org>
Subject: Re: `git fetch` not updating 'origin/HEAD' after branch rename
Date: Wed, 14 Apr 2021 12:56:27 +0200	[thread overview]
Message-ID: <87sg3t16ec.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <CAPx1GvdeNEyPEZ7GdRKeAevnvjyLmoXHjQP0W6iToDsJPAqDHA@mail.gmail.com>


On Wed, Apr 14 2021, Chris Torek wrote:

> On Tue, Apr 13, 2021 at 5:18 PM Sam Bostock <sam.bostock@shopify.com> wrote:
>> Long story short, it seems to me that `git fetch` should update
>> "refs/remotes/origin/HEAD" when the upstream HEAD changes, but it
>> doesn't.
>
> It's never been the *intent* to have `git fetch` update
> the corresponding remote-tracking `HEAD` ref.  To make
> that happen, you must run `git remote`:
>
>     git remote set-head origin -a
>
> for instance.
>
> I have, however, often thought that this is the wrong
> *default* way for things to work, and that at least by default,
> `git fetch origin` should update `origin/HEAD` if the
> fetch result indicates that it should.  See also Junio's
> reply.  I think a configuration knob (similar to `fetch.prune`)
> would be reasonable here.  Users could then be encouraged
> to set `fetch.prune` to `true`, and `fetch.update-remote-HEAD`
> (or whatever) to `true` as well.

As you'll see from the previous linked thread I happen to agree with
you, but let's not step past that agreement and (no doubt subtly and
unintentionally, in this case) misrepresent the other side, which also
has a legitimate argument.

Which is that this notion that "[a client should update its view of a
remote to what a] fetch result indicates that it should" isn't something
that exists, and that we ever had it is only an emergent implementation
detail.

So first of all, a "fetch result" doesn't look anything like
that. Rather the server presents refs it has, and the client decides
what it wants.

Which is the start of the disconnect in mental models around this. What
you see with "git ls-remote origin" != what you should expect to have at
a local refs/remotes/origin/* after a fetch.

Nothing in git itself actually needs this remote HEAD past clone time,
and with 4f37d457065 (clone: respect remote unborn HEAD, 2021-02-05)
there'll be even less reason to pay attention to it.

We don't even always get it on "clone", we don't do it with "--bare",
since the reason we do it is to one-time setup the default branch, which
we then hardcode in the config in the non-bare case:

    [remote "origin"]
            url = https://github.com/git/git.git
            fetch = +refs/heads/*:refs/remotes/origin/*
    [branch "master"]
            remote = origin
            merge = refs/heads/master

So arguably the bug is the other way around, that we should never save
this information at all in the ref store at "clone" time, which would
make "init && config && fetch" and "clone" consistent.

I haven't looked, but wouldn't be surprised to discover that this was
originally needed back when we needed to ferry information between
shellscripts, and was just diligently retained when the relevant parts
were rewritten in C.

But I digress.

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?

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?

If we supported "I want the tip of your HEAD" (which we do) or "I have
this ref update for you, on top of your idea of HEAD" (we don't) you
could "git push" and it would do the right thing whether the primary
branch was renamed from "master" to "main" during your "git push" or
not.

  parent reply	other threads:[~2021-04-14 10:56 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-13 20:25 `git fetch` not updating 'origin/HEAD' after branch rename Sam Bostock
2021-04-13 20:37 ` Junio C Hamano
2021-04-13 21:09   ` Andreas Schwab
2021-04-13 21:22     ` Junio C Hamano
2021-04-14  0:26 ` Chris Torek
2021-04-14  5:29   ` Jeff King
2021-04-14 10:56   ` Ævar Arnfjörð Bjarmason [this message]
2021-04-14 12:03     ` Andreas Schwab
2021-04-14 21:12       ` Junio C Hamano
2021-04-15  9:28     ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87sg3t16ec.fsf@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=chris.torek@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=sam.bostock@shopify.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).