From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Andreas Krey <a.krey@gmx.de>, Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH 1/3] upload-pack: send the HEAD information
Date: Sun, 8 Sep 2013 03:13:59 -0400 [thread overview]
Message-ID: <20130908071359.GJ14019@sigill.intra.peff.net> (raw)
In-Reply-To: <xmqqsixhyhan.fsf@gitster.dls.corp.google.com>
On Fri, Sep 06, 2013 at 10:46:24AM -0700, Junio C Hamano wrote:
> I think it is perfectly fine to expose _only_ HEAD now, and wait
> until we find a good reason that we should send this information for
> other symbolic refs in the repository.
Yeah, I agree with that.
> However, because we already anticipate that we may find such a good
> reason later, on-the-wire format should be prepared to support such
> later enhancement. I think sending
>
> symref=HEAD:refs/heads/master
>
> is probably one good way to do so, as Peff suggested in that old
> thread ($gmane/102070; note that back then this wasn't suggested as
> a proper capability so the exact format he suggests in the message
> is different). Then we could later add advertisements for other
> symbolic refs if we find it necessary to do so, e.g.
>
> symref=HEAD:refs/heads/master
> symref=refs/remotes/origin/HEAD:refs/remotes/origin/master
>
> (all on one line together with other capabilities separated with a
> SP in between).
It somehow feels a little weird to me that we would output the
information about refs/foo on the HEAD line. A few possible issues (and
I am playing devil's advocate to some degree here):
1. What if we have a large number of symrefs? Would we run afoul of
pkt-line length limits?
2. What's the impact of having to display all symrefs on the first
line, before we output other refs? Right now we can just stream out
refs as we read them, but we would have to make two passes (and/or
cache them all) to find all of the symrefs before we start
outputting. Will the extra latency ever matter?
What do you think about teaching git to read extra data after "\0" for
_every_ ref line? And then ref advertisement might look something like:
<sha1> HEAD\0multi_ack thin-pack ... symref=refs/heads/master\n
<sha1> refs/heads/master\n
<sha1> refs/heads/my-alias\0symref=refs/heads/master
That would leave us future room for more ref annotations if we should
want them, and I think (but haven't tested) that existing receivers
should ignore everything after the NUL.
-Peff
next prev parent reply other threads:[~2013-09-08 7:14 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-06 15:52 [PATCH 0/3] Unconfuse git clone when two branches at are HEAD Andreas Krey
2013-09-06 15:56 ` [PATCH 1/3] upload-pack: send the HEAD information Andreas Krey
2013-09-06 17:46 ` Junio C Hamano
2013-09-06 19:29 ` Andreas Krey
2013-09-06 19:54 ` Junio C Hamano
2013-09-08 7:13 ` Jeff King [this message]
2013-09-08 7:22 ` Jeff King
2013-09-08 17:27 ` Junio C Hamano
2013-09-18 2:31 ` [PATCH v2 0/6] Removing the guesswork of HEAD in "clone" Junio C Hamano
2013-09-18 2:31 ` [PATCH v2 1/6] upload-pack.c: do not pass confusing cb_data to mark_our_ref() Junio C Hamano
2013-09-18 2:31 ` [PATCH v2 2/6] upload-pack: send symbolic ref information as capability Junio C Hamano
2013-09-18 4:36 ` Junio C Hamano
2013-09-18 2:31 ` [PATCH v2 3/6] upload-pack: send non-HEAD symbolic refs Junio C Hamano
2013-09-18 2:31 ` [PATCH v2 4/6] connect.c: make parse_feature_value() static Junio C Hamano
2013-09-18 2:31 ` [PATCH v2 5/6] connect: annotate refs with their symref information in get_remote_head() Junio C Hamano
2013-09-18 2:31 ` [PATCH v2 6/6] clone: test the new HEAD detection logic Junio C Hamano
2013-09-06 15:56 ` [PATCH 2/3] connect.c: save symref info from server capabilities Andreas Krey
2013-09-06 17:56 ` Junio C Hamano
2013-09-06 19:25 ` Andreas Krey
2013-09-06 19:46 ` Junio C Hamano
2013-09-06 15:57 ` [PATCH 3/3] clone: test the new HEAD detection logic Andreas Krey
2013-09-06 17:29 ` [PATCH 0/3] Unconfuse git clone when two branches at are HEAD Philip Oakley
2013-09-06 18:17 ` Junio C Hamano
2013-09-06 23:19 ` Philip Oakley
2013-09-07 15:50 ` Junio C Hamano
2013-09-07 19:19 ` Philip Oakley
2013-09-08 17:35 ` Junio C Hamano
2013-09-08 21:00 ` Philip Oakley
2013-09-09 14:44 ` Junio C Hamano
2013-09-09 16:08 ` Andreas Krey
2013-09-09 22:20 ` Philip Oakley
2013-09-09 22:26 ` Junio C Hamano
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=20130908071359.GJ14019@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=a.krey@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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.
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).