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

From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Martin Langhoff <martin.langhoff@gmail.com>,
	Junio C Hamano <gitster@pobox.com>,
	e@80x24.org, Git Mailing List <git@vger.kernel.org>
Subject: Re: git svn clone/fetch hits issues with gc --auto
Date: Wed, 10 Oct 2018 20:38:23 +0200	[thread overview]
Message-ID: <87va69ejfk.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <20181010165152.GA180779@aiede.svl.corp.google.com>

On Wed, Oct 10 2018, Jonathan Nieder wrote:

> 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/