git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Stefan-W. Hahn" <stefan.hahn@s-hahn.de>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Florian Breitwieser <florian.bw@gmail.com>, git@vger.kernel.org
Subject: Re: Recover broken git repository?
Date: Tue, 14 Jul 2009 19:48:19 +0200	[thread overview]
Message-ID: <20090714174819.GC9919@scotty.home> (raw)
In-Reply-To: <alpine.LFD.2.01.0907141019380.13838@localhost.localdomain>

Also sprach Linus Torvalds am Tue, 14 Jul 2009 at 10:33:58 -0700:
> 
> 
> On Tue, 14 Jul 2009, Florian Breitwieser wrote:
> >
> > $ git commit -m "Some message"
> > error: invalid object 1086b1c606a04bcb78b92d1d411a299d20d18034
> > fatal: Error building trees
> 
> Hmm. That "invalid object" error comes from 'update_one()' when it cannot 
> find the object it is looking for. That, in turn, tends to be an issue of 
> the index containing a SHA1 that does not exist in the database.
> 
> Do you trust your filesystem? The symptoms really sound like you did a 
> "git add .." earlier, and populated the index, but now the object that got 
> populated is no longer found.
> 
> What OS, what filesystem?  Oh, and what version of git?
> 
> > $ git-fsck --full
> > dangling tree c2549a3cdd83098a523cb707f217f4656cde7eb5
> 
> The fsck seems to imply that things are ok. The fsck _should_ have checked 
> the index too.
> 
> The 'git commit' obviously disagrees.
> 
> Two things to check:
> 
>  - do you use grafts to hide old history, rather than connect additional 
>    history?
> 
>    That can be really dangerous, and will make fsck (and other tools) not 
>    look at the hidden state. 
> 
>  - do you have alternates (is multiple _different_ repositories tat point 
>    to each other)? That can cause problems if you then do things like git 
>    prune in them. It wouldn't explain this particular case, but it's 
>    something I look out for when I hear about corruption.
> 
> > $ git prune
> 
> Not a good idea. When you suspect corruption, the _last_ thing you want to 
> do is prune things. Who knows what happened?
> 
> > $ git commit -m "Some message"
> > Created commit e32d5dd: Some message
> >  2 files changed, 167 insertions(+), 10 deletions(-)
> 
> So now the same commit worked? It _really_ sounds like your filesystem has 
> a hard time finding the files it just created. Some local caching issue.
> 
> Is it a network filesystem? If so, what's the filesystem server and 
> version, if you can find it out?
> 
> > $ git push
> > Counting objects: 15, done.
> > Compressing objects: 100% (6/6), done.
> > Writing objects: 100% (8/8), 2.44 KiB, done.
> > Total 8 (delta 4), reused 0 (delta 0)
> > Unpacking objects: 100% (8/8), done.
> > fatal: unresolved deltas left after unpacking
> > error: unpack failed: unpacker exited with error code
> > To /mnt/extstore2/bioinformatic/git/ppi.git
> >  ! [remote rejected] master -> master (n/a (unpacker error))
> > error: failed to push some refs to
> > '/mnt/extstore2/bioinformatic/git/ppi.git'
> 
> Here the other end doesn't have some object that we expect it to have, and 
> that we sent a delta to it against. Sounds like potentially the exact same 
> problem (it created some new file, but then couldn't see it). Is the thign 
> you are pushing to a similar machine with similar filesystems?
> 
> We've had issues with both CIFS and NFS. Using
> 
> 	[core]
> 		fsyncobjectfiles = true
> 
> might work around some issues where the filesystem does crazy things. But 
> I'd really like to hear what OS and filesystem versions you're running.
> 
> 			Linus
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Stefan-W. Hahn                          It is easy to make things.
/ mailto:stefan.hahn@s-hahn.de /        It is hard to make things simple.			

Please note that according to the German law on data retention,
information on every electronic information exchange with me is
retained for a period of six months.
Bundesgesetzblatt:
http://www.bgblportal.de/BGBL/bgbl1f/bgbl107s3198.pdf

  reply	other threads:[~2009-07-14 17:48 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-14 13:20 Recover broken git repository? Florian Breitwieser
2009-07-14 14:40 ` Alex Riesen
2009-07-14 14:54 ` Nicolas Sebrecht
2009-07-14 15:20   ` Jakub Narebski
2009-07-14 17:33 ` Linus Torvalds
2009-07-14 17:48   ` Stefan-W. Hahn [this message]
2009-07-14 17:52   ` Stefan-W. Hahn
2009-07-14 18:25   ` [PATCH] Improve on the 'invalid object' error message at commit time Linus Torvalds
2009-07-14 19:43     ` Junio C Hamano

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20090714174819.GC9919@scotty.home \
    --to=stefan.hahn@s-hahn.de \
    --cc=florian.bw@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).