archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <>
To: Alexander Litvinov <>
Cc: Git Mailing List <>
Subject: Re: My git repo is broken, how to fix it ?
Date: Thu, 22 Mar 2007 09:17:11 -0700 (PDT)	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

[ 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!


  parent reply	other threads:[~2007-03-22 16:17 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-28  4:36 My git repo is broken, how to fix it ? Alexander Litvinov
2007-02-28  4:57 ` Linus Torvalds
2007-02-28 11:54   ` Alexander Litvinov
2007-02-28 16:19     ` Linus Torvalds
2007-02-28 19:12       ` Alex Riesen
2007-03-19 13:32       ` Alexander Litvinov
2007-03-19 15:20         ` Linus Torvalds
     [not found]           ` <>
2007-03-20  5:34             ` Linus Torvalds
2007-03-20  6:55               ` Alexander Litvinov
2007-03-20  7:42               ` Junio C Hamano
2007-03-20 15:23                 ` Nicolas Pitre
     [not found] ` <>
     [not found]   ` <>
     [not found]     ` <>
2007-03-22 15:58       ` Linus Torvalds
2007-03-22 16:34         ` Nicolas Pitre
     [not found]       ` <>
2007-03-22 16:17         ` Linus Torvalds [this message]
2007-03-22 16:29           ` Linus Torvalds
2007-03-22 16:48             ` Linus Torvalds
2007-03-22 17:01               ` Nicolas Pitre
2007-03-22 17:10                 ` Linus Torvalds
2007-03-22 17:28                   ` Nicolas Pitre
2007-03-22 22:13                   ` Jeff King
2007-03-23  0:25                     ` Linus Torvalds
2007-03-23  0:42                       ` Bill Lear
2007-03-23  0:51                       ` Jeff King
2007-03-22 20:31               ` [PATCH] git-apply: Do not free the wrong buffer when we convert the data for writeout Junio C Hamano
2007-03-22 20:55                 ` Linus Torvalds
2007-03-23  3:55                   ` Alexander Litvinov
2007-03-23  3:40               ` My git repo is broken, how to fix it ? Alexander Litvinov
2007-03-22 17:12             ` Johannes Sixt
2021-06-06 17:27 B
2021-06-06 17:28 B
2021-12-25  8:30 Joseph Mitchell
2021-12-26  0:48 ` Lemuria
2023-05-29 18:57 ross thomas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).