On Friday 2006, December 15 21:55, Junio C Hamano wrote: > Thanks --- very much appreciated. When it comes to > inter-repository object transfer, we take compatibility very > seriously. Okay. Before I started bisecting I thought I'd do some other experiments. Having tested fetch from remote and a fetch from local and finding the same results, I've done all the tests locally. So; here goes. I've got these directories: linux-partial/ (this is every patch from v1.0.0 to v2.1.63) linux-full/ (this is every patch from v1.0.0 to v2.5.75) linux-partial/ is the one I reported the original error on, later I confirmed that the same error happened with a local fetch from linux-full. I cloned both of these. linux-partial-clone/ (made with git clone linux-partial linux-partial-clone) linux-full-clone/ (made with git clone linux-full linux-full-clone) Tests: - A fetch from linux-full to linux-partial, this one failed with error 128 - A fetch from linux-full-clone to linux-partial, this one failed with error 128 - A fetch from linux-full to linux-partial-clone, this one succeeded - A fetch from linux-full-clone to linux-partial-clone, this one succeeded (unsurprisingly) Next I ran git-prune in linux-partial. The fetch then succeeded. Bizarre. So, the strange result is that it is a difference in the destination directory that is triggering the error, and whatever that fault is is fixed by git-cloning that destination repository, or git-pruning the destination. Unfortunately I've now lost my test case, because the prune fixed it. Bah. Oh well, this fault can be marked "on hold until I get it to fail again". Andy -- Dr Andrew Parkins, M Eng (Hons), AMIEE andyparkins@xxxxxxxxx - 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