Re: People unaware of the importance of "git gc"?
- From
David Kastrup <dak@gnu.org>
- Date
- Sep 5, 2007, 09:13 UTC
- Message-ID
- <864pi9cw4w.fsf@lola.quinscape.zz>
- In-Reply-To
- <46DE6DBC.30704@midwinter.com>
Steven Grimm <koreth@midwinter.com> writes:
Show 14 quoted lines
> Pierre Habouzit wrote: >> 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