Re: People unaware of the importance of "git gc"?

[Carl Worth <cworth@cworth.org>]

[-- Attachment #1: Type: text/plain, Size: 3615 bytes --]

On Wed, 5 Sep 2007 11:47:45 -0500, "Govind Salinas" wrote:
> I know this goes against the general mood here (which seems to be
> against auto-gc) but I thought I would give my $.02 as a user of git.

I'll throw my opinion in here as well. I think git should
automatically do repacking by default, (once loose objects exceed some
threshold). There have several posts in this thread from people who
don't want auto-gc, but these same people should be able to avoid it,
and likely without changing habits. That's because:

  * They're already in the habit of manually repacking every once in a
    while, (or like, Linus, much more often than strictly necessary).

  * They've already got cron jobs setup to do the repacking.

And one could augment this with an option to disable the repacking of
course.

And if you're really concerned about people that don't want this
getting it anyway, just determine some useful threshold and then
double it or so before it triggers automatic repacking, (so the
automatic repacking hits only us idiots that completely neglect it).

[Pardon me for continuing to quote in the original top-posted order,
but I like the flow here.]

On 9/5/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > James didn't seem to realize that the fact that he had apparently never
> > ever repacked his repository was a big deal.

I know it was surprising to you, Linus, but I'm glad you noticed
it. I've seen the same thing from many users. And git actually
discourages users from learning about repacking. If the user starts
with a small (or new) project, then everything performs well, and
there's no performance problem whatsoever.

So then the problems creep up gradually, and the user has no idea that
he should be doing anything different than he's always done. Instead
the user is left to just conclude that git's performance isn't scaling
well as the project grows. That's a bad conclusion of course, and it's
bad that git sets things up so the user reaches that conclusion.
Instead, git should just fix things up itself in this case.

> > I've been against automatic repacking, but that was really based on what
> > appears to be potentially a very wrong assumption, namely that people
> > would do the manual repack on their own. If it turns out that people don't
> > do it, maybe the right thing for git to do really is to at least notify
> > people when they have way too many pack-files and/or loose
> > objects.

I don't think the warning message alone is a good fix. I think the
people who would understand the warning and appreciate that they could
then take care of repacking as convenient are the same people that
already understand the repacking concept, and are likely already
repacking occasionally, (so would likely never see the warning).

But the problematic case is the user who knows nothing of the
issue. And in that case, giving this warning isn't useful education,
it's just forcing the user to learn more and do more work. "If git
notices it has too many 'loose object' and 'git gc' would fix the
problem, then why didn't it do that itself? And what the heck is a
'loose object' anyway?"

In general, git has always printed too many obscure messages that
don't actually help a new user get his work done, (and the work is
_not_ to learn more about git internals). From 1.4 to 1.5 much of that
was improved. But please let's not go backwards by adding more of
these.

So one vote from me for auto repacking, (but feel free to make the
threshold so high that anyone that actually _cares_ about loose
objects and repacking will never get the auto repack).

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]