Re: auto gc again

[Jens Axboe <jens.axboe@oracle.com>]

On Wed, Mar 19 2008, Nicolas Pitre wrote:
> On Wed, 19 Mar 2008, Jens Axboe wrote:
> 
> > On Wed, Mar 19 2008, Nicolas Pitre wrote:
> > > On Tue, 18 Mar 2008, Jens Axboe wrote:
> > > 
> > > > But freshly pulled repo, git auto gc is enabled. And that is my main
> > > > annoyance, I just don't think that type of policy should be in there.
> > > 
> > > Just do this once:
> > > 
> > > 	git config --global gc.auto 0
> > > 	git config --global gc.autopacklimit 0
> > > 
> > > and be happy.
> > 
> > You don't get it. I did gc.auto 0. And know some other limit crops up, I
> > have to do gc.autopacklimit 0. I have LOTS of git trees. On many
> > machines. It's just annoying, period.
> 
> As suggested, gc.auto = 0 should probably be made to disable it 
> entirely, regardless of any other parameters that might exist.

Yes, agree.

> > > > Print the warning, include info on how to run git gc or even how to turn
> > > > it on automatically. But I'll bet you that most users will NOT want auto
> > > > gc. Ever.
> > > 
> > > Unfortunately, the harshest complaints about this whole issue were the 
> > > opposite.
> > 
> > I just don't buy that, I have more faith in users.
> 
> We also did in the past... even for a long period...
> 
> Alas, it is the users who made us (and actually made Linus, who was the 
> last to resist) change our minds.

OK, that's at least reassuring :-)

> > If they come around and complain it's slow, heck you told them it 
> > would be.
> 
> But they don't.  They just presume that Git is crap and move on.

That's pretty sad, I like to have high hopes for users.

> > But it's not a big deal, I'll just carry a local patch that disables
> > this crap and forget the whole deal. I just worry that if this is where
> > git 'usability' is heading, it wont be a good thing in the long run.
> 
> I wish the majority of users was thinking like you.  I, too, have some 
> conceptual problems with this auto gc things.  With the experience 
> we've gathered, the current state appears to be the 
> lesser of all evils though.

Alright, I must bow down to empirical evidence... The conceptual policy
problem is indeed what is bothering me so much, even more so than the
actual gc running on my machine.

gc.auto covering everything is good enough for me, GIT_GC_AUTO
environment variable would be better because of the way that I work. But
I can get by knowing that the gc.auto thing will at least only bite me
once per tree. And perhaps just wrap git clone in one of my scripts
that'll then do the gc.auto thing automatically.

-- 
Jens Axboe