Re: Odd behavior with git and cairo-devel repo

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

 



On Wed, Jun 21, 2006 at 04:46:05AM +0200, Andre Noll wrote:
> On 20:00, Art Haas wrote:
> 
> > $ git clone git://git.cairographics.org/git/cairo cairo
> > [ ... git clones the repo without problem ... ]
> > $ cd cairo
> > $ git fsck-objects
> > Floating point exception
> 
> This is due to refs_hash_size being zero in mark_reachable().
> Both "git fsck-objects --full" and "git repack -a -d" seem to work
> fine with the patch below (tested by cloning your repo).
> 
> [ ... snip ... ]

Hi.

I see this patch has made it into git now, and it fixes the problem
described above. Thanks!

However, I'm still seeing the problem where 'git prune' leaves the
repo in an invalid state. In the case above, running 'git prune' on a
freshly checked-out repo works without problems; when the repo has a
number of unpacked objects, however, things go bad. On the FC4 machine
I have, I updated my git repo, rebuilt, and installed the build with
the patch above, then updated my cairo repo. The 'git pull' retrieved
a handful of objects, and 'git fsck-objects' ran without problem.
Then 'git prune' was run, seemingly without problem, and when I tried
'git repack -a -d' things went boom. A subsequent 'git fsck-object'
run indicated the repo was missing tree and commit objects.

Is anyone else seeing a similar problem with 'git prune'?

Art Haas
-- 
Man once surrendering his reason, has no remaining guard against absurdities
the most monstrous, and like a ship without rudder, is the sport of every wind.

-Thomas Jefferson to James Smith, 1822
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[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]