From: Julian Phillips Date: Fri, 02 Nov 2007 00:26:34 GMT Subject: Re: Debugging corrupt object generation Message-ID: In-Reply-To: On Thu, 1 Nov 2007, Nicolas Pitre wrote: > On Thu, 1 Nov 2007, Julian Phillips wrote: > >> After a certain commit, and attempt to use that commit generates a "fatal: >> unable to apply delta". This appears to be coming from unpack_delta_entry >> in sha1_file.c. > > I suppose you mean "fatal: failed to apply delta", because "unable to > apply delta" doesn't appear anywhere in the current source tree. I did indeed. Read 'n' type never seems to be as reliable as copy 'n' paste ... >> Can anyone give me any hints as to how I find out what is causing the >> problem? I'm not even sure what it is that isn't working ... and all >> attempts to replicate the problem with my test repository have failed. > > Well, something is screwed for sure. Some object you're requesting is > made of a delta, and that delta is bad, therefore patch_delta() returns > NULL (you could instrument it to determine exactly why). Ah, ok - that sounds like it might be useful. I guess that looking at the opposite side where fast-import is creating the data might also prove fruitful. > Maybe fast-import hasn't flushed the needed data to the pack yet? Well, fast-import completes quite happily and outputs the normal summary status. I can look at logs and trees etc provided that I don't try and look at one particular part of the tree on one particular commit. I think the problem is that I've managed to do something inside fast-import that corrupts one particular tree object (though I've no idea what that might be). I shall have to start instrumenting and try again. Thanks. -- Julian --- Many changes of mind and mood; do not hesitate too long.