From: Martin Langhoff Date: Wed, 19 Oct 2005 09:06:52 GMT Subject: Re: cg-clone, tag objects and cg-push/git-push don't play nice Message-ID: <46a038f90510190206j722faefbl4fe60ed0052b7104@mail.gmail.com> In-Reply-To: <7vbr1ldh30.fsf@assigned-by-dhcp.cox.net> On 10/19/05, Junio C Hamano 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. > 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? > 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, m