Re: git svn clone/fetch hits issues with gc --auto

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Oct 10, 2018, 18:38 UTC
Message-ID: <87va69ejfk.fsf@evledraar.gmail.com>
In-Reply-To: <20181010165152.GA180779@aiede.svl.corp.google.com>

On Wed, Oct 10 2018, Jonathan Nieder wrote:

Show 28 quoted lines

> Hi,
>
> Ævar Arnfjörð Bjarmason wrote:
>
>> I'm just saying it's hard in this case to remove one piece without the
>> whole Jenga tower collapsing, and it's probably a good idea in some of
>> these cases to pester the user about what he wants, but probably not via
>> gc --auto emitting the same warning every time, e.g. in one of these
>> threads I suggested maybe "git status" should emit this.
>
> I have to say, I don't have a lot of sympathy for this.
>
> I've been running with the patches I sent before for a while now, and
> the behavior that they create is great.  I think we can make further
> refinements on top.  To put it another way, I haven't actually
> experienced any bad knock-on effects, and I think other feature
> requests can be addressed separately.
>
> I do have sympathy for some wishes for changes to "git gc --auto"
> behavior (I think it should be synchronous regardless of config and
> the asynchrony should move to being requested explicitly through a
> command line option by the callers within Git) but I don't understand
> why this holds up a change that IMHO is wholly positive for users.
>
> To put it another way, I am getting the feeling that the objections to
> that series were theoretical, while the practical benefits of the
> patch are pretty immediate and real.  I'm happy to help anyone who
> wants to polish it but time has shown no one is working on that, so...

[I wrote this before seeing Jeff's reply, but just to bo clear...]

Yes, like Jeff says I'm not referring to your gitster/jn/gc-auto with this "Jenga tower" comment.

Re that patch: I've said what I think about tools printing error messages saying "I can't do stuff" while not returning a non-zero exit code, so I won't repeat that here. But whatever anyone thinks of that it's ultimately a rather trivial detail, and doesn't have any knock-on effects on the rest of git-gc behavior.

I'm talking about the "gc: do not warn about too many loose objects" patch and similar approaches. FWIW what I'm describing in <878t36f3ed.fsf@evledraar.gmail.com> isn't some theoretical concern. In some large repositories at work that experience a lot of branch churn and have fetch.prune / fetch.pruneTags turned on active checkouts very quickly get to the default 6700 limit.

I've currently found that gc.pruneExpire=4.days.ago is close to a sweet spot of avoiding that issue for now, while not e.g. gc-ing a loose object someone committed on Friday before the same time on Monday, but before I tweaked that, but with the default of 2.weeks we'd much more regularly see the problem described in [1].

But as noted in the various GC threads linked from this one that sort of solution within the confines of the current implementation and configuration promises we've made, which lead to all sorts of stupidity.

1. https://public-inbox.org/git/87inc89j38.fsf@evledraar.gmail.com/