On Tue, 10 Jun 2008, Denis Bueno wrote:
> >
> > Hmm. Scary. That should *not* have been successful with a corrupt repo.
> >
> > Unless you have done a .grafts file to hide the corruption, or something
> > like that?
>
> I intended to do that, yes, and I think I was successful.
Ahh, ok. Yes, we should probably re-think our 'grafts' file thing, or at
least not document it, because it's actually a wondeful way to just cause
more corruption by hiding things (ie if you clone a repo with a grafts
file, the result will now have neither the grafts file _nor_ the state
that was hidden by it, so the result is guaranteed to be corrupt).
But that explains why your clone worked, and why the resulting repo had
different corruption - it avoided the original corruption, but because of
the grafts file it avoided it by just not having those commits at all..
> I do have bunches of personal information in the repo, unfortunately.
> The particular *file* involved in the corruption, however, is fine for
> all to view. Is that useful?
No, almost all the interest is basically in how the whole repo ties
together. The individual corrupt files may be interesting, though, ie from
your original report:
error: 320bd6e82267b71dd2ca7043ea3f61dbbca16109: object corrupt or missing
error: 4d0be2816d5eea5ae2b40990235e2225c1715927: object corrupt or missing
then *if* you have the files
.git/objects/32/0bd6e82267b71dd2ca7043ea3f61dbbca16109
.git/objects/4d/0be2816d5eea5ae2b40990235e2225c1715927
then those two files are interesting in themselves (most likely they are
not there at all, or are zero-sized, but if you have them, please post
them).
And as this was a result of a real filesystem crash, it *is* possible that
you have something in the /lost+found directory for that filesystem. If
so, those missing files may be found there.
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
