Hi,
Uwe Kleine-KÃnig wrote:
> ukl@hostname:~/path1/linux-2.6$ git fetch ~/path2/linux-2.6 sectionmismatches
> remote: Counting objects: 118, done.
> remote: error: unable to find 40aaeb204dc04d3cf15c060133f65538b43b13b0
> remote: Compressing objects: 100% (83/83), done.
> remote: fatal: unable to read 40aaeb204dc04d3cf15c060133f65538b43b13b0
> error: git upload-pack: git-pack-objects died with error.
> fatal: git upload-pack: aborting due to possible repository corruption on the remote side.
Sounds like alternates or workdir allowed gc to be overzealous, indeed.
Could you:
1. Make a copy of the corrupted repo, just in case.
2. Explode all backs with "git unpack-objects"
3. Identify the missing object, as explained in
Documentation/howto/recover-corrupted-blob-object.txt?
With that information, it would be easier to examine whether and how
pack-objects could be smarter about fetching the non-missing objects.
> I don't know what 40aaeb204dc04d3cf15c060133f65538b43b13b0 is, but I
> think it's not necessary for the sectionmismatches branch:
>
> ukl@hostname:~/path2/linux-2.6$ git format-patch linus/master..sectionmismatches
> 0001-wip-enable-DEBUG_SECTION_MISMATCH.patch
[...]
> and linus/master is contained in ~/path1/linux-2.6, too.
Cc-ing Nico, pack-objects wizard.
Thanks for reporting.
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