Re: [RFC] gc: correct gc.autoPackLimit documentation

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

 



Jeff King <peff@xxxxxxxx> wrote:
> On Sat, Jun 25, 2016 at 01:14:50AM +0000, Eric Wong wrote:
> 
> > I'm not sure if this is the best approach, or if changing
> > too_many_packs can be done without causing problems for
> > hosts of big repos.
> > 
> > -------8<-----
> > Subject: [PATCH] gc: correct gc.autoPackLimit documentation
> > 
> > I want to ensure there is only one pack in my repo to take
> > advantage of pack bitmaps.  Based on my reading of the
> > documentation, I configured gc.autoPackLimit=1 which led to
> > "gc --auto" constantly trying to repack on every invocation.
> 
> I'm not sure if you might be misinterpreting earlier advice on bitmaps
> here. At the time of packing, bitmaps need for all of the objects to go
> to a single pack (they cannot handle a case where one object in the pack
> can reach another object that is not in the pack). But that is easily
> done with "git repack -adb".
> 
> After that packing, you can add new packs that do not have bitmaps, and
> the bitmaps will gracefully degrade. E.g., imagine master was at tip X
> when you repacked with bitmaps, and now somebody has pushed to make it
> tip Y.  Somebody then clones, asking for Y. The bitmap code will start
> at Y and walk backwards. When it hits X, it stops walking as it can fill
> in the rest of the reachability from there.

Ah, thanks, makes sense.  I was misinterpreting earlier advice
on bitmaps.

> That's neither here nor there for the off-by-one in gc or its
> documentation, of course, but just FYI.

I'm now inclined to fix the problem in gc and leave the
documentation as-is (unless it cause other problems...)
--
To unsubscribe from this list: 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]