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

Steven Grimm [off-list ref] writes:

Pierre Habouzit wrote:

quoted

  Well independently from the fact that one could suppose that users
should use gc on their own, the big nasty problem with repacking is that
it's really slow. And I just can't imagine git that I use to commit
blazingly fast, will then be unavailable for a very long time (repacks
on my projects -- that are not as big as the kernel but still -- usually
take more than 10 to 20 seconds each).
  

What about kicking off a repack in the background at the ends of
certain commands? With an option to disable, of course. It could run
at a low priority and could even sleep a lot to avoid saturating the
system's disks -- since it'd be running asynchronously there should
be no problem if it takes longer to run.

You'll potentially get accumulating unfinished files from
aborted/killed repack processes.  If communication fails, you'll get a
new repack session for every command you start.  If a repository is
used by multiple people...

And so on.  The multiuser aspect makes it a bad idea to do any
janitorial tasks automatically.  You don't really want every user to
start a repack at the same time.

-- 
David Kastrup