Steven Grimm <koreth@xxxxxxxxxxxxx> writes: > 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
