Re: cg-clone, tag objects and cg-push/git-push don't play nice

From: Martin Langhoff <martin.langhoff@gmail.com>
Date: Oct 19, 2005, 09:06 UTC
Message-ID: <46a038f90510190206j722faefbl4fe60ed0052b7104@mail.gmail.com>
In-Reply-To: <7vbr1ldh30.fsf@assigned-by-dhcp.cox.net>

On 10/19/05, Junio C Hamano <junkio@cox.net> wrote:

> Yeah.  But the problem is that the repository on the other end
> claims that it has everything reachable from those incomplete
> tags.

It definitely does.

Show 7 quoted lines

> Hearing that, git-push (the real name of it is send-pack)
> decides not to send things that are already reachable from the
> refs the other end claims to have.  So if an incomplete tag
> refers to a commit that contains a blob that the remote actually
> does not have, and if that blob is part of the head you are
> pushing, send-pack would not (and should not) send that blob to
> the remote.

*shrug* it's a bit over my head, but I've figured out taht git-fetch-pack is segfaulting. Perhaps that helps?

Show 22 quoted lines

> Hmph.  It worries me even more.
>
> This error message:
>
>       error: unpack should have generated
>     482d4b88aa482dfea7f7549470902049a050020a, but I can't find it!
>
> comes from receive-pack that runs on the other repo (i.e. the
> one with incomplete tags you just removed), so it means
> send-pack decided it does not need to send that object --
> meaning the other end claimed it already has it.  What to send
> and what need not to be sent is determined solely based on what
> send-pack hears from receive-pack in the initial handshake,
> which is in receive-pack.c::write_head_info().  It scans
> everything under ".git/refs" directory (not just .git/refs/heads
> or .git/refs/tags; if you had ".git/refs/FOOBAR", it will cause
> the remote end to claim it has everything reachable from it --
> the only exceptions are things that starts with a dot '.', which
> is probably why cg-fetch places a temporary heads in
> refs/*/.$name-fetching) and sends them -- it does not look at
> the object directory and magically claim it has something that
> is not recorded in its .git/refs/ directory.

*Very* strange. The remote repo is packed, but is working well for everyone else. I think we should follow the segfault and see where it leads...

cheers,