All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Jonathan Tan <jonathantanmy@google.com>
Cc: git@vger.kernel.org, spearce@spearce.org, sbeller@google.com,
	peff@peff.net, gitster@pobox.com
Subject: Re: [PATCH v3 2/2] connect: advertized capability is not a ref
Date: Wed, 7 Sep 2016 18:34:31 -0700	[thread overview]
Message-ID: <20160908013431.GC25016@google.com> (raw)
In-Reply-To: <4b09bb7a5b7f4eb5fc31df3d98ce7ffc042eb367.1473291819.git.jonathantanmy@google.com>

Jonathan Tan wrote:

> Git advertises the same capabilities^{} ref in its ref advertisement for push
> but since it never remembered to do so for fetch, the client forgot to handle
> this case. Handle it.

The comment in the previous review was that this doesn't describe the
history correctly.  It can instead say something like

	Git advertises the same capabilities^{} ref in its ref advertisement for push
	but since it never did so for fetch, the client didn't need to handle this
	case. Handle it.

[...]
> @@ -165,8 +166,24 @@ struct ref **get_remote_heads(int in, char *src_buf, size_t src_len,
>  			continue;
>  		}
>  
> +		if (!strcmp(name, "capabilities^{}")) {
> +			if (got_at_least_one_head)
> +				warning("protocol error: unexpected dummy ref for "
> +				        "capabilities declaration, continuing anyway");

Can this die() instead of warning?

I think mentioning capabilities^{} in the error message would make it
easier to debug.

> +			if (got_dummy_ref_with_capabilities_declaration)
> +				warning("protocol error: multiple dummy refs for "
> +				        "capabilities declaration, continuing anyway");

Likewise.

> +			got_dummy_ref_with_capabilities_declaration = 1;
> +			continue;

I think we can make this stricter.  The capabilities^{} line is supposed
to be the first advertised ref, before any 'shallow' lines or .have
extra refs.

(Alas, Documentation/technical/pack-protocol.txt doesn't describe
.have refs --- v1.6.1-rc1~203^2~1, push: prepare sender to receive
extended ref information from the receiver, 2008-09-09.)

'die_initial_contact' uses got_at_least_one_head to determine whether
it was on the first line but code paths added later that use
'continue' don't populate it properly (see b06dcd7d, 40c155ff, and
1a7141ff).  We could do

	int first_line = 1;

	for (;; first_line = 0) {
		...
	}

and use !first_line instead of got_at_least_one_head (removing
got_at_least_one_head in the process since it has no other purpose).

Thanks,
Jonathan

  reply	other threads:[~2016-09-08  1:34 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-02 17:15 [PATCH 0/2] handle empty spec-compliant remote repos correctly Jonathan Tan
2016-09-02 17:15 ` [PATCH 1/2] tests: move test_lazy_prereq JGIT to test-lib.sh Jonathan Tan
2016-09-02 17:15 ` [PATCH 2/2] connect: know that zero-ID is not a ref Jonathan Tan
2016-09-02 19:37   ` Jonathan Nieder
2016-09-02 19:39   ` Shawn Pearce
2016-09-02 19:56     ` Stefan Beller
2016-09-02 20:00       ` Shawn Pearce
2016-09-02 20:13   ` Jeff King
2016-09-02 22:11     ` Jonathan Tan
2016-09-02 23:19       ` Jeff King
2016-09-03  2:03     ` Shawn Pearce
2016-09-03  2:17       ` Jeff King
2016-09-02 22:06 ` [PATCH v2 0/2] handle empty spec-compliant remote repos correctly Jonathan Tan
2016-09-02 22:06   ` [PATCH v2 1/2] tests: move test_lazy_prereq JGIT to test-lib.sh Jonathan Tan
2016-09-07 16:47     ` Junio C Hamano
2016-09-02 22:06   ` [PATCH v2 2/2] connect: advertized capability is not a ref Jonathan Tan
2016-09-02 22:40     ` Jonathan Nieder
2016-09-02 23:35     ` Jeff King
2016-09-02 23:48       ` Stefan Beller
2016-09-03  0:37         ` Jonathan Nieder
2016-09-02 23:51       ` Jonathan Nieder
2016-09-03  0:56         ` Jeff King
2016-09-07 17:02     ` Junio C Hamano
2016-09-07 17:10     ` Junio C Hamano
2016-09-07 20:38       ` Jonathan Nieder
2016-09-07 23:02         ` Junio C Hamano
2016-09-07 23:50 ` [PATCH v3 0/2] handle empty spec-compliant remote repos correctly Jonathan Tan
2016-09-07 23:50   ` [PATCH v3 1/2] tests: move test_lazy_prereq JGIT to test-lib.sh Jonathan Tan
2016-09-07 23:50   ` [PATCH v3 2/2] connect: advertized capability is not a ref Jonathan Tan
2016-09-08  1:34     ` Jonathan Nieder [this message]
2016-09-08  1:45       ` [PATCH] connect: tighten check for unexpected early hang up (Re: [PATCH v3 2/2] connect: advertized capability is not a ref) Jonathan Nieder
2016-09-08  1:46         ` Jonathan Nieder
2016-09-08  1:50         ` Jonathan Nieder
2016-09-08 16:42           ` Junio C Hamano
2016-09-08 16:28         ` Stefan Beller
2016-09-08 16:18       ` [PATCH v3 2/2] connect: advertized capability is not a ref Junio C Hamano
2016-09-09 17:36 ` [PATCH v4 0/3] handle empty spec-compliant remote repos correctly Jonathan Tan
2016-09-09 17:36   ` [PATCH v4 1/3] tests: move test_lazy_prereq JGIT to test-lib.sh Jonathan Tan
2016-09-10  5:51     ` Torsten Bögershausen
2016-09-10  6:00       ` Jeff King
2016-09-09 17:36   ` [PATCH v4 2/3] connect: tighten check for unexpected early hang up Jonathan Tan
2016-09-09 17:36   ` [PATCH v4 3/3] connect: advertized capability is not a ref Jonathan Tan
2016-09-09 19:40     ` Jonathan Nieder
2016-09-09 20:40       ` Junio C Hamano
2016-09-09 20:09     ` Junio C Hamano
2016-09-09 20:17 ` [PATCH v5 0/3] handle empty spec-compliant remote repos correctly Jonathan Tan
2016-09-09 20:17   ` [PATCH v5 1/3] tests: move test_lazy_prereq JGIT to test-lib.sh Jonathan Tan
2016-09-09 20:17   ` [PATCH v5 2/3] connect: tighten check for unexpected early hang up Jonathan Tan
2016-09-09 20:17   ` [PATCH v5 3/3] connect: advertized capability is not a ref Jonathan Tan
2016-09-09 21:07   ` [PATCH v5 0/3] handle empty spec-compliant remote repos correctly Jonathan Nieder

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=20160908013431.GC25016@google.com \
    --to=jrnieder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jonathantanmy@google.com \
    --cc=peff@peff.net \
    --cc=sbeller@google.com \
    --cc=spearce@spearce.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.