On Thu, Jan 11 2018, Ævar Arnfjörð Bjarmason jotted:
> I recently disabled gc.auto=0 and my nightly aggressive repack script on
> our big monorepo across our infra, relying instead on git gc --auto in
> the background to just do its thing.
>
> I didn't want users to wait for git-gc, and I'd writt
On Fri, Jan 12, 2018 at 09:23:05PM +0700, Duy Nguyen wrote:
> > > Why can't we generate a new cruft-pack on every gc run that
> > > detects too many unreachable objects? That would not be as
> > > efficient as a single cruft-pack but it should be way more
> > > efficient than the individual object
On Fri, Jan 12 2018, Duy Nguyen jotted:
> On Fri, Jan 12, 2018 at 4:33 AM, Ævar Arnfjörð Bjarmason
> wrote:
>> For those rusty on git-gc's defaults, this is what it looks like in this
>> scenario:
>>
>> 1. User runs "git pull"
>> 2. git gc --auto is called, there are >6700 loose objects
>> 3.
On Fri, Jan 12, 2018 at 08:46:09AM -0500, Jeff King wrote:
> On Thu, Jan 11, 2018 at 10:33:15PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
> > 4. At the end of all this, we check *again* if we have >6700 objects,
> > if we do we print "run 'git prune'" to .git/gc.log, and will just
> > emit
On Thu, Jan 11, 2018 at 10:33:15PM +0100, Ævar Arnfjörð Bjarmason wrote:
> 4. At the end of all this, we check *again* if we have >6700 objects,
> if we do we print "run 'git prune'" to .git/gc.log, and will just
> emit that error for the next day before trying again, at which point
>
On Fri, Jan 12, 2018 at 7:07 PM, Duy Nguyen wrote:
>> More generally, these hard limits seem contrary to what the user cares
>> about. E.g. I suspect that most of these loose objects come from
>> branches since deleted in upstream, whose objects could have a different
>> retention policy.
>
> Er..
On Fri, Jan 12, 2018 at 4:33 AM, Ævar Arnfjörð Bjarmason
wrote:
> For those rusty on git-gc's defaults, this is what it looks like in this
> scenario:
>
> 1. User runs "git pull"
> 2. git gc --auto is called, there are >6700 loose objects
> 3. it forks into the background, tries to prune and re
I recently disabled gc.auto=0 and my nightly aggressive repack script on
our big monorepo across our infra, relying instead on git gc --auto in
the background to just do its thing.
I didn't want users to wait for git-gc, and I'd written this nightly
cronjob before git-gc learned to detach to the b
8 matches
Mail list logo