On Tue, 19 Oct 2010, Jonathan Nieder wrote:
> Nicolas Pitre wrote:
>
> > 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.
Sure. Given that it is possible to create a patch series, that means
that all the important objects are still available. Therefore Git
should be able to produce the pack for the equivalent fetch/bundle as
well.
So the following patch should help. I hope that Uwe still has a copy of
the broken repo to test this patch with.
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index f8eba53..691c2f1 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -1299,6 +1299,15 @@ static int try_delta(struct unpacked *trg, struct unpacked *src,
src->data = read_sha1_file(src_entry->idx.sha1, &type, &sz);
read_unlock();
if (!src->data)
+ if (src_entry->preferred_base) {
+ /*
+ * Those objects are not included in the
+ * resulting pack. Be resilient and ignore
+ * them, in case the pack could be created
+ * nevertheless.
+ */
+ return 0;
+ }
die("object %s cannot be read",
sha1_to_hex(src_entry->idx.sha1));
if (sz != src_size)
Nicolas
--
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