Re: git-fetch fails with error code 128

Hello,

This is with my big "every linux patch" repository that I talked about in another thread. To bring you up to speed:

 1. Made repository
 2. Made a zip of the .git directory
 3. Copied the zip elsewhere
 4. Extracted it into a temporary directory
 5. Went to an out-of-date version of this repository
 6. Used git-fetch to update it.

This gave me the following output:

$ git fetch remote: Generating pack... remote: Done counting 189146 objects. remote: Result has 186566 objects. remote: Deltifying 186566 objects. remote: 100% (186566/186566) done Unpacking 186566 objects fatal: failed to apply delta fatal: unpack-objects died with error code 128 Fetch failure: /home/andyp/projects/temp/.git

What does that mean? I ran fsck --full on the source repository, but it's made no difference.

Andy

Andy Parkins <andyparkins@gmail.com> wrote:

Bad voodoo. What does 'git fetch -k' do? It uses slightly different code for handling the deltas...

Andy Parkins <andyparkins@gmail.com> writes:

Andy, which version of git do you run (I presume they are the same version, as you are doing the local fetching), and which version of git was the "slightly out of date" repository prepared with?

I think this is the second time I've seen a report of unpacker barfing on the mailing list. Nico, anything rings a bell?

On Friday 2006 December 15 00:02, Junio C Hamano wrote:

One of them is switched off and in another place at the moment, so this is from memory:

The initial repository was made with origin/master from a few days ago, that's the one I've been calling "out-of-date". I cloned that to another computer and continued adding patches using "1.4.4.1.g3ece-dirty" (the dirt is just my colour branch patch on top of ba988a83). The fetch is being done back on the original system which has the newer git but older repository.

I hadn't realised it was quite a serious as these responses are making it sound. I'll gather more precise data upon my return home.

On the up-to-date computer I've just made a fresh repository, set .git/config to point locally at the full repository and ran git-fetch. Interestingly, that has worked perfectly.

Clearly it is version-specific. I'll do a bit of bisection later and see if I can nail the problem down.

Andy

Andy Parkins <andyparkins@gmail.com> writes:

Thanks --- very much appreciated. When it comes to inter-repository object transfer, we take compatibility very seriously.

On Fri, 15 Dec 2006, Junio C Hamano wrote:

I really doubt it is a compatibility problem. The provided error message may only result from the fact that patch_delta() has returned NULL.

And since patch-delta is really simple, it doesn't have many reasons for returning NULL: either the object store on either the remote or local side is corrupted in which case a git-fsck-objects --full should catch that, or the system ran out of memory.

Nicolas Pitre <nico@cam.org> writes:

Hmmmm. True and sad. Sad because I do not offhand think of places to trim the memory usage.

On Friday 2006, December 15 22:13, Nicolas Pitre wrote:

It's not conclusive, but the system its failing on has more memory than the system it is working on.

Andy

On Friday 2006, December 15 21:55, Junio C Hamano wrote:

Okay. Before I started bisecting I thought I'd do some other experiments. Having tested fetch from remote and a fetch from local and finding the same results, I've done all the tests locally.

So; here goes.  I've got these directories:

 linux-partial/   (this is every patch from v1.0.0 to v2.1.63)
 linux-full/      (this is every patch from v1.0.0 to v2.5.75)

linux-partial/ is the one I reported the original error on, later I confirmed that the same error happened with a local fetch from linux-full. I cloned both of these.

 linux-partial-clone/  (made with git clone linux-partial linux-partial-clone)
 linux-full-clone/     (made with git clone linux-full linux-full-clone)

Tests:
 - A fetch from linux-full to linux-partial, this one failed with error 128
 - A fetch from linux-full-clone to linux-partial, this one failed with
   error 128
 - A fetch from linux-full to linux-partial-clone, this one succeeded
 - A fetch from linux-full-clone to linux-partial-clone, this one succeeded
   (unsurprisingly)

Next I ran git-prune in linux-partial.  The fetch then succeeded.  Bizarre.

So, the strange result is that it is a difference in the destination directory that is triggering the error, and whatever that fault is is fixed by git-cloning that destination repository, or git-pruning the destination.

Unfortunately I've now lost my test case, because the prune fixed it. Bah. Oh well, this fault can be marked "on hold until I get it to fail again".

Andy

On Thu, 14 Dec 2006, Andy Parkins wrote:

Could you please instrument patch-delta.c to determine which of the "return NULL" is executed?