Re: Debugging strange "corrupt pack" errors on SuSE 9

From: Martin Langhoff <martin.langhoff@gmail.com>
Date: Jun 20, 2007, 04:17 UTC
Message-ID: <46a038f90706192117x53420c04o27f05e8fa6c338a5@mail.gmail.com>
In-Reply-To: <alpine.LFD.0.99.0706192313290.20596@xanadu.home>

On 6/20/07, Nicolas Pitre <nico@cam.org> wrote:

> The full exact error message would be highly useful indeed.

Yes. I haven't seen it first hand either, and the machine is closely guarded :-/ but I think you are on to something: it's a v1.4.0.

# git --version

> git version 1.4.0

# cat /etc/issue Welcome to SUSE LINUX Enterprise Server 9 (i586) - Kernel \r (\l). # uname -a Linux lhostname 2.6.5-7.244-bigsmp-100hz #3 SMP Sun Aug 13 21:50:35 NZST 2006 i686 i686 i386 GNU/Linux

The errors look like

# git-pull /home/jun/moodle-r2.git ird-mk2:fromusb fatal: git-unpack-objects exec failed fatal: git-unpack-objects died with error code 128 Fetch failure: /home/jun/moodle-r2.git

# cg-update fromusb
Using hard links
Fetching head...
Fetching objects...
Getting pack 445d79a6fe09a3d03489449f63faef0d9e9e2668
 which contains 4f4773fb3403f3ec4097ab7c7b1fdec23b9aa924
fatal: corrupted pack file
.git/objects/pack/pack-445d79a6fe09a3d03489449f63faef0d9e9e2668.pack
progress: 2 objects, 0 bytes
cg-fetch: objects fetch failed

> Maybe the client machine runs git version < 1.4.2.2, in which case it is
> possible that your push created a pack containing delta objects with
> offset to base which git versions prior 1.4.2.2 do not understand.

Ouch. We weren't supposed to have non-backwards compatible changes...

> If this is the problem you are facing (the error message should confirm
> this) then the easiest solution is to upgrade git on the client.

Ha ha. Not particularly easy, unfortunately.

> A quick fix for the client is to set repack.usedeltabaseoffset to
> false on the machine where you have git 1.5 installed, then run "git
> repack -a -d", and finally copy the pack over to the client repository.

That'll be a bit easier -- it's a fix we can do on the transfer repo ourselves.

Thanks! I do wonder though -- isn't a backwards-incompatible change like this worthy of don't we bump core.repositoryformatversion?

> But because you push to a local repository (a mounted USB stick is
> considered a local repo) then you don't get to negociate the pack
> capabilities of the final destination, and therefore more "bad" delta
> objects might sneak in again.

How does that work? So any repo we push _from_ can override (and muck up) the destination repo, ignoring its config?

That sounds a bit broken - the pack being built for a local destination should respect the settings of the destination repo.