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

On 6/20/07, Nicolas Pitre [off-list ref] 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