git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).