Hi,
[out of order for convenience]
Nicolas Pitre wrote:
> On Tue, 19 Oct 2010, Uwe Kleine-KÃnig wrote:
>> and I'm running git-fsck --full now over night as it's bedtime here.
>
> Given that you exploded your repo into loose objects, it'll take _time_.
Yep, I gave bad advice. :( Especially because I forgot that a fsck
would be useful at all.
Better advice would be:
1. Use "git rev-list --objects" to find out what 40aaeb204dc was.
And if that doesn't work:
2. Run "git fsck", with packs intact. This will take a while. The
result would include a list of missing objects (like 40aaeb204dc),
and, most importantly, their type.
Following howto/recover-corrupted-blob-object.txt would be useful for
identifying a corrupt loose object, but iiuc no corrupt objects are
involved here, anyway.
> But ideally you should simply find a
> pack that contains the problematic object in another repository and copy
> it with its index
> file into the broken repository.
I assume the object is gone for good, but if you have it in another
repo that would be interesting, too.
To be clear: I think the important data has been recovered from the
broken repo already in the form of patches (right?) so the question
at hand is whether it would be possible to teach git to do better at
recovering automatically. Which might depend on the nature of the
missing objects.
Ciao,
Jonathan
--
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