On 07:06, Art Haas wrote: > I see this patch has made it into git now, and it fixes the problem > described above. Thanks! > > However, I'm still seeing the problem where 'git prune' leaves the > repo in an invalid state. In the case above, running 'git prune' on a > freshly checked-out repo works without problems; when the repo has a > number of unpacked objects, however, things go bad. On the FC4 machine > I have, I updated my git repo, rebuilt, and installed the build with > the patch above, then updated my cairo repo. The 'git pull' retrieved > a handful of objects, and 'git fsck-objects' ran without problem. > Then 'git prune' was run, seemingly without problem, and when I tried > 'git repack -a -d' things went boom. A subsequent 'git fsck-object' > run indicated the repo was missing tree and commit objects. > > Is anyone else seeing a similar problem with 'git prune'? Yeah. This is due to a thinko in grow_refs_hash() which was introduced in commit 3e4339e6f96e8c4f38a9c6607b98d3e96a2ed783 Author: Linus Torvalds <torvalds@xxxxxxxx> Date: Sun Jun 18 11:45:02 2006 -0700 Remove "refs" field from "struct object" Fix below. --- Fix grow_refs_hash() As the hash values depend on the hash size, they have to be recalulated when growing the hash. It's possible (though unlikely) that there are duplicates even with the new, larger hash size, so make grow_refs_hash() check for duplicates. Signed-off-by: Andre Noll <maan@xxxxxxxxxxxxxxx> --- diff --git a/object-refs.c b/object-refs.c index 8afa227..fa1d3c1 100644 --- a/object-refs.c +++ b/object-refs.c @@ -25,6 +25,8 @@ static void grow_refs_hash(void) if (!ref) continue; j = hash_obj(ref->base, new_hash_size); + while (new_hash[j]) + j = (j + 1) % new_hash_size; new_hash[j] = ref; } free(refs_hash); -- The only person who always got his work done by Friday was Robinson Crusoe - : 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