git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Felipe Contreras <felipe.contreras@gmail.com>,
	git@vger.kernel.org, Jonathan Nieder <jrnieder@gmail.com>,
	Dominik Salvet <dominik.salvet@gmail.com>
Subject: Re: [RFC/PATCH] Add fetch.updateHead option
Date: Fri, 20 Nov 2020 19:40:33 -0500
Message-ID: <20201121004033.GD353076@coredump.intra.peff.net> (raw)
In-Reply-To: <xmqq3613tuwy.fsf@gitster.c.googlers.com>

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

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

  reply	other threads:[~2020-11-21  0:41 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-18  9:12 Felipe Contreras
2020-11-18  9:30 ` Ævar Arnfjörð Bjarmason
2020-11-18  9:43   ` Felipe Contreras
2020-11-18 15:53   ` Junio C Hamano
2020-11-18 19:04     ` Felipe Contreras
2020-11-20 23:52 ` Jeff King
2020-11-21  0:28   ` Junio C Hamano
2020-11-21  0:40     ` Jeff King [this message]
2020-11-21  1:18       ` Felipe Contreras
2020-11-24  6:58         ` Jeff King
2020-11-21  1:53     ` Felipe Contreras
2020-11-21  1:41   ` Felipe Contreras
2020-11-24  7:09     ` 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=20201121004033.GD353076@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=dominik.salvet@gmail.com \
    --cc=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.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

git@vger.kernel.org list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ https://public-inbox.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git
 note: .onion URLs require Tor: https://www.torproject.org/

code repositories for the project(s) associated with this inbox:

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

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git