Re: git-fetch fails with error code 128
- From
- Andy Parkins <andyparkins@gmail.com>
- Date
- Dec 16, 2006, 22:12 UTC
- Message-ID
- <200612162212.57771.andyparkins@gmail.com>
- In-Reply-To
- <7vy7p8omdh.fsf@assigned-by-dhcp.cox.net>
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