Re: fetch and bundle don't work in (semi-)broken repo

From: Nicolas Pitre <nico@fluxnic.net>
Date: Oct 20, 2010, 03:06 UTC
Message-ID: <alpine.LFD.2.00.1010192154200.2764@xanadu.home>
In-Reply-To: <20101019210233.GA32029@burratino>

On Tue, 19 Oct 2010, Jonathan Nieder wrote:

Show 14 quoted lines

> 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