On 07/31/2007 20:38, "Linus Torvalds" <torvalds@linux-foundation.org> wrote:
quoted text
> Please do
> 
> cd /Volumes/work/scripts
> git fsck --full
> 
> which I would guess will almost certainly talk about some kind of problems
> with that object "b28b949a1a3c8eb37ca6eefd024508fa8b253429". And possibly
> more.

Indeed:

    scripts[10] > git fsck --full
    error: b28b949a1a3c8eb37ca6eefd024508fa8b253429: object corrupt or
missing
    missing blob b28b949a1a3c8eb37ca6eefd024508fa8b253429

Fortunately, it's the only one.

quoted text
> There are certainly ways to figure out what that object _should_ be,
> though. For example, if that object is the only corrupted entry, and it's
> a blob (ie pure data object), what you can generally do is still use the
> repo (as long as you avoid that particular blob), and do things like
> 
> git log --raw -r --no-abbrev

    scripts[11] > git log --raw -r --no-abbrev | grep
b28b949a1a3c8eb37ca6eefd024508fa8b253429
    :100755 100755 b28b949a1a3c8eb37ca6eefd024508fa8b253429
9dbd5bb59198ab59e1850f838f2ed27c77364cde M      condor/condor-uninstall.sh
    :000000 100755 0000000000000000000000000000000000000000
b28b949a1a3c8eb37ca6eefd024508fa8b253429 A      condor/condor-uninstall.sh

quoted text
> and you'll see the git history with all blobs named with their SHA1's.
> Then you can just search for that b28b949.. name, and you'll see exactly
> which file (in which version) it was, and if you can just find a backup of
> that file (or re-create it *exactly* from previous versions and your
> memory of it), you can re-generate the git object and thus save your
> repository.

When you say "re-generate", do you mean `git add <file> ; git commit
<file>`?  Or something a bit more clever?  I suspect you actually meant the
latter, since you suggest recreating it *exactly*.

If I just recreate a version I'm happy with, can I add that to the repo and
go from there?

quoted text
> Of course, a much easier option tends to be to just have a backup
> repository that has that object in it, and then you can literally just
> copy that b28b949 object over.

No such luck, but I'll back up my repos in the future.  Any hint on what
might have caused this kind of corruption?  That repo was created on my
laptop and only edited there; it's not a clone from some other machine.
It's possible that I have Ctrl-C'd some git operation in the past -- could
that have caused it?

Is there anything (e.g. trapping signals if a blob is being written until
it's done, or backing out of the current blob on SIG{INT,HUP}) that could
make this kind of corruption less easy to encounter?  I ask because I have
used VC systems (i.e. CVS, SVN, darcs, and now git) for 4+ years (not long
by any means, but long enough) and the only repository corruption I had ever
encountered was after I went mucking about in a CVS repo's internal
representation -- and I deserved that.


                      Denis
--
"Dealing with failure is easy: Work hard to improve. Success is also easy to
handle: You've solved the wrong problem. Work hard to improve." -- Perlis


-
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