All of lore.kernel.org
 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 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.