[ Git list cc'd again - I modified your branch names and commit header line just in case you care about those ] On Wed, 21 Mar 2007, Alexander Litvinov wrote: > > I have a good news : I got the breakage again. And I can reproduce it :-) > > This is a version of git with three your patches. > > Here is the steps to broke my repo: So does it break every time if you do this particular sequence with the particular state that it has? If so, wonderful, since it should mean that you can also recreate the file that got corrupted as a blob. > $ git prune > $ git fsck --full > dangling commit 50267ccaa820c456bd361db808f99d81714cbce8 > $ git rebase fix-autoxyzzy > First, rewinding head to replay your work on top of it... > HEAD is now at 42af3b2... Replace ... > Applying 'Show ...' > > Wrote tree 851c5d8d2213c60efc1bd081b0012bfcc9e558b5 > Committed: e7117e5637e881368ff04e94a27dca2abdb12d38 And then.. > [lan@ac-7923bb4c6c14 navitel (debug-autoxyzzy)]$ git fsck --full > error: corrupt loose object 'c01848491b53c3dcfd738149193a14d3c9abe107' > error: c01848491b53c3dcfd738149193a14d3c9abe107: object corrupt or missing > missing blob c01848491b53c3dcfd738149193a14d3c9abe107 > dangling commit 50267ccaa820c456bd361db808f99d81714cbce8 > > What can I do to debug this ? Every time there's a corrupt object, if you can send it to me, that would be good. If you can tell the source for the corrupt object and can send that to me too, that's always even better, but even in the absense of that, the more corrupt objects I have, the better the chances that I see some pattern. And if it's always the same object that gets corrupted the same way when you start from a particular starting point, that would also be very interesting to know. Considering that the "don't use hardlinks on cygwin" thing didn't matter for you (and really, I would have only expected it to matter if you used ^C to kill a process in the middle or something), you migth also be better off just trackng the standard git, since it now has Nicos extra consistency checks over and beyond those I send you. It's also possible that the real bug is that we have some memory scribble internally in git, and that it shows up for you just because Cygwin and/or WinXp has different allocation patterns than other platforms. Do you know if there are any "debugging malloc" libraries for Cygwin? Something like ElectricFence/dmalloc under Linux, or running with valgrind. Since it happens after a single rebase, if it's a git bug (as opposed to,for example, a zlib problem or simply a problem in your combination of vmware/winxp/cygwin), it would be the recursive merge that screws up. It *is* one of the more complex operations (especially if it also ends up doing file-level merging, which I assume it does), so some memory allocation problem there is not out of the question, although it's strange that you see it but the (many more) users on UNIX never seem to - it's not like rebase is an uncommon operation! Linus - 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