From: Andy Parkins <andyparkins@gmail.com>
To: git@vger.kernel.org
Cc: Junio C Hamano <junkio@cox.net>, Nicolas Pitre <nico@cam.org>
Subject: Re: git-fetch fails with error code 128
Date: Sat, 16 Dec 2006 22:12:55 +0000 [thread overview]
Message-ID: <200612162212.57771.andyparkins@gmail.com> (raw)
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
next prev parent reply other threads:[~2006-12-16 22:15 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-14 23:08 git-fetch fails with error code 128 Andy Parkins
2006-12-14 23:19 ` Shawn Pearce
2006-12-14 23:25 ` Horst H. von Brand
2006-12-15 2:31 ` Nicolas Pitre
2006-12-15 0:02 ` Junio C Hamano
2006-12-15 9:46 ` Andy Parkins
2006-12-15 21:55 ` Junio C Hamano
2006-12-15 22:13 ` Nicolas Pitre
2006-12-16 0:37 ` Junio C Hamano
2006-12-16 13:29 ` Andy Parkins
2006-12-16 22:12 ` Andy Parkins [this message]
2006-12-15 2:25 ` Nicolas Pitre
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200612162212.57771.andyparkins@gmail.com \
--to=andyparkins@gmail.com \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
--cc=nico@cam.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.