Re: [RFC/PATCH] Add fetch.updateHead option

From: Jeff King <peff@peff.net>
Date: Nov 21, 2020, 00:40 UTC
Message-ID: <20201121004033.GD353076@coredump.intra.peff.net>
In-Reply-To: <xmqq3613tuwy.fsf@gitster.c.googlers.com>

On Fri, Nov 20, 2020 at 04:28:45PM -0800, Junio C Hamano wrote:

Show 13 quoted lines

> > This won't resolve a symref pointing to an unborn branch, so it would
> > count as "missing". I.e.:
> >
> >   git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/nope
> >   git -c fetch.updatehead=missing fetch
> >
> > will update it based on the remote HEAD.  I guess I could see some
> > argument for defining "missing" in that way, but I suspect it is not
> > what somebody in this situation would expect.
> 
> What do we do in "git clone" of an empty repository with the current
> branch not yet to be born?  Modern Git tells where the HEAD points at
> even for unborn branch, so using that would be a natural thing to do.

We don't seem to do anything:

  $ git init
  $ git clone . dst
  Cloning into 'dst'...
  warning: You appear to have cloned an empty repository.
  done.
  $ find dst/.git/refs
  dst/.git/refs
  dst/.git/refs/tags
  dst/.git/refs/heads

Likewise with --no-local.

I don't think we do advertise the symref in such a case. In v2, the symref information is attached to individual lines in the ref advertisement. And we don't advertise the unborn line (we could, but I think we might need a special syntax for the oid field).

In v0, it comes in the capability section attached to the first line of the advertisement, but it doesn't have to be about that particular line. If there are no refs to advertise, we don't seem to send anything (I _thought_ we sent a capabilities^{} line, but I think that is only receive-pack; if we have no refs to fetch, then capabilities are not interesting on the upload-pack side anyway).

But even if we do have a ref in v0, it looks like we don't advertise the symref:

  $ git init
  $ git commit --allow-empty -m foo
  $ git checkout --orphan another-branch
  $ git-upload-pack .
  0104d4cebe701d3d7b36e6c383193e92ef4bd49ab2b0 refs/heads/mastermulti_ack thin-pack side-band side-band-64k ofs-delta shallow deepen-since deepen-not deepen-relative no-progress include-tag multi_ack_detailed object-format=sha1 agent=git/2.29.2.730.g3e418f96ba

We could likewise support it there, but I don't think modifying the v0 protocol at this point is that interesting.

-Peff