Re: regression in 92392b4

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jul 23, 2008 at 11:37:00AM +0000, Johannes Schindelin wrote:
> Hi,
> 
> On Wed, 23 Jul 2008, Pierre Habouzit wrote:
> 
> > On Wed, Jul 23, 2008 at 10:49:04AM +0000, Johannes Schindelin wrote:
> > 
> > > On Wed, 23 Jul 2008, Björn Steinbrink wrote:
> > > Funny.  That does not reproduce the bug here at all.
> > > 
> > > But then, it is unsurprising, since both Pierre and me did something 
> > > similar yesterday, fetching _just_ the pre-fetch refs into a freshly 
> > > initted Git repository, and then fetching from kernel.org.
> > > 
> > > Tested on x86_64.
> > 
> > I can reproduce on x86_64 here.
> 
> Well, I cannot.  However, I get some pread issue on i686.  To be nice to 
> kernel.org, I downloaded the pack in question:
> 
> 	http://pacific.mpi-cbg.de/git/thin-pack.pack
> 
> You should be able to reproduce the behavior by piping this into
> 
> git-index-pack --stdin -v --fix-thin --keep=fetch-pack --pack_header=2,263

  I can reproduce. Funily enough, I just happened to see that I have
core.deltabasecachelimit = 0 in my git.git repository... which I
probably used meaning -1 but oh well. The bottom line is that the
pruning algorithm likely removes a pointer we still have a pointer to
somewhere...


-- 
·O·  Pierre Habouzit
··O                                                madcoder@xxxxxxxxxx
OOO                                                http://www.madism.org

Attachment: pgphuupUOAKt4.pgp
Description: PGP signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux