From: Junio C Hamano <gitster@pobox.com>
To: Andreas Krey <a.krey@gmx.de>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH 1/3] upload-pack: send the HEAD information
Date: Fri, 06 Sep 2013 10:46:24 -0700 [thread overview]
Message-ID: <xmqqsixhyhan.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20130906155608.GF12966@inner.h.apk.li> (Andreas Krey's message of "Fri, 6 Sep 2013 17:56:08 +0200")
Andreas Krey <a.krey@gmx.de> writes:
> From: Junio C Hamano <gitster@pobox.com>
>
> This implements the server side of protocol extension to show which branch
> the HEAD points at. The information is sent as a capability symref=<target>.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> Signed-off-by: Andreas Krey <a.krey@gmx.de>
> ---
> upload-pack.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/upload-pack.c b/upload-pack.c
> index 127e59a..390d1ec 100644
> --- a/upload-pack.c
> +++ b/upload-pack.c
> @@ -745,13 +745,17 @@ static int send_ref(const char *refname, const unsigned char *sha1, int flag, vo
> if (mark_our_ref(refname, sha1, flag, cb_data))
> return 0;
>
> - if (capabilities)
> - packet_write(1, "%s %s%c%s%s%s agent=%s\n",
> + if (capabilities) {
> + unsigned char dummy[20];
> + const char *target = resolve_ref_unsafe("HEAD", dummy, 0, NULL);
> + packet_write(1, "%s %s%c%s%s%s%s%s agent=%s\n",
> sha1_to_hex(sha1), refname_nons,
> 0, capabilities,
> allow_tip_sha1_in_want ? " allow-tip-sha1-in-want" : "",
> stateless_rpc ? " no-done" : "",
> + target ? " symref=" : "", target ? target : 0,
> git_user_agent_sanitized());
> + }
> else
> packet_write(1, "%s %s\n", sha1_to_hex(sha1), refname_nons);
> capabilities = NULL;
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.
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).
next prev parent reply other threads:[~2013-09-06 17:46 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 [this message]
2013-09-06 19:29 ` Andreas Krey
2013-09-06 19:54 ` Junio C Hamano
2013-09-08 7:13 ` Jeff King
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=xmqqsixhyhan.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=a.krey@gmx.de \
--cc=git@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.