On 6/20/07, Nicolas Pitre <nico@xxxxxxx> 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
