From: Linus Torvalds <torvalds@linux-foundation.org>
To: Florian Breitwieser <florian.bw@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Recover broken git repository?
Date: Tue, 14 Jul 2009 10:33:58 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.2.01.0907141019380.13838@localhost.localdomain> (raw)
In-Reply-To: <1247577632053-3255106.post@n2.nabble.com>
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
next prev parent reply other threads:[~2009-07-14 17:35 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 [this message]
2009-07-14 17:48 ` Stefan-W. Hahn
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=alpine.LFD.2.01.0907141019380.13838@localhost.localdomain \
--to=torvalds@linux-foundation.org \
--cc=florian.bw@gmail.com \
--cc=git@vger.kernel.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).