Stephen Bannasch <stephen.bannasch@xxxxxxxxxxxxx> writes:
> At 7:30 PM -0800 1/27/09, Shawn O. Pearce wrote:
>>PJ - the short story here is, to forever work around these buggy
>>1.6.1 clients, you'd have to either run an old server forever,
>>or forever run a patched server that disables the newer ".have"
>>extension in the advertised data written by git-upload-pack.
>>There just isn't a way to hide this from the client.
>>
>>Really though, I'd recommend getting your users to upgrade to a
>>non-buggy client. Pasky has the same problem on repo.or.cz; if
>>he doesn't have it already he will soon when he upgrades...
>
> Do you know if this problem is fixed in tag v1.6.1.1?
>
> Tagger: Junio C Hamano <gitster@xxxxxxxxx>
> Date: Sun Jan 25 12:41:48 2009 -0800
> commit 5c415311f743ccb11a50f350ff1c385778f049d6
Give us a break. This was reported today and diagnosed a few hours ago.
In the meantime, here is a minimum patch that should help you to help us
convince the approach we decided to take would work fine for people.
connect.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git c/connect.c w/connect.c
index 2f23ab3..8026850 100644
--- c/connect.c
+++ w/connect.c
@@ -43,6 +43,9 @@ int check_ref_type(const struct ref *ref, int flags)
static void add_extra_have(struct extra_have_objects *extra, unsigned char *sha1)
{
+ if (!has_sha1_file(sha1))
+ return;
+
ALLOC_GROW(extra->array, extra->nr + 1, extra->alloc);
hashcpy(&(extra->array[extra->nr][0]), sha1);
extra->nr++;
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
