From: Martin Langhoff Date: Wed, 20 Jun 2007 04:17:11 GMT Subject: Re: Debugging strange "corrupt pack" errors on SuSE 9 Message-ID: <46a038f90706192117x53420c04o27f05e8fa6c338a5@mail.gmail.com> In-Reply-To: On 6/20/07, Nicolas Pitre 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. m