git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Philip Oakley" <philipoakley@iee.org>,
	"Félix Saparelli" <felix@passcod.name>,
	git@vger.kernel.org
Subject: Re: [Non-Bug] cloning a repository with a default MASTER branch tries to check out the master branch
Date: Thu, 25 May 2017 15:11:15 -0400	[thread overview]
Message-ID: <20170525191115.tqd6zlj5mxqls4wp@sigill.intra.peff.net> (raw)
In-Reply-To: <20170525155924.hk5jskennph6tta3@sigill.intra.peff.net>

On Thu, May 25, 2017 at 11:59:24AM -0400, Jeff King wrote:

> The just-HEAD case could look like:

This patch does work, in the sense that upload-pack advertises the
unborn HEAD symref. But the client doesn't actually do anything with it.
The capability parsing happens in get_remote_heads(), which passes the
data out by adding an annotation to the "struct ref" list. But of course
we have no HEAD ref to annotate.

So either get_remote_heads() would have to start returning a bogus HEAD
ref (with a null sha1, I guess, which all callers would have to
recognize). Or clone (and probably "remote set-head -a") would have to
start reaching across the transport-module boundary and asking for any
symref values for "HEAD". I'm not excited about more special-casing of
"HEAD", though. In theory we'd want this for other symrefs in the long
run, and it would be nice if clients were ready to handle that (even if
the protocol isn't quite there).

I dunno. I was thinking there might be a quick tweak, but I'm wondering
if this arcane case is worth the restructuring we'd have to do to
support it. It only comes up when you've moved the server repo's HEAD to
an unborn branch _and_ you have other refs (since otherwise we don't
even send capabilities at all!).

-Peff

  reply	other threads:[~2017-05-25 19:11 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-22 21:42 [Bug] cloning a repository with a default MASTER branch tries to check out the master branch Félix Saparelli
2017-05-23  3:40 ` [Non-Bug] " Junio C Hamano
2017-05-23 23:24   ` Philip Oakley
2017-05-24 14:19     ` Jeff King
2017-05-25  1:36       ` Junio C Hamano
2017-05-25  3:13         ` Junio C Hamano
2017-05-25 15:59           ` Jeff King
2017-05-25 19:11             ` Jeff King [this message]
2017-05-25 23:28               ` Junio C Hamano
2017-05-26 20:00               ` Philip Oakley
2017-05-26 21:17                 ` Philip Oakley
2017-05-27 23:55                 ` Junio C Hamano
2017-05-28 11:21                   ` Philip Oakley
2017-05-28 12:57                     ` Junio C Hamano
2017-05-31  4:43                     ` Jeff King
2017-05-23  8:01 ` [Bug] " Samuel Lijin
2017-05-23 12:12   ` 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

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

  git send-email \
    --in-reply-to=20170525191115.tqd6zlj5mxqls4wp@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=felix@passcod.name \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=philipoakley@iee.org \
    /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.
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 NNTP newsgroup(s).