On 5 Sep 2007, Pierre Habouzit said:
I know I don't really answer the question, but the point I try to make
is that yeah, some kind of automated way to run the gc is great, but I'm
not sure that _git_ is the tool to automate that, because when *I* use
git, I expect it to be just plain fast, and I don't want it to
occasionally hang.
Indeed. I repack all our git trees in the middle of the night, and our
incremental backup script drops .keep files corresponding to every
existing pack before running the backup.
This is probably a good job for cron :)
Nix wrote:
Indeed. I repack all our git trees in the middle of the night, and our
incremental backup script drops .keep files corresponding to every
existing pack before running the backup.
This is probably a good job for cron :)
If you are setting up cron jobs to repack multiple git trees, you are
not the kind of novice or casual git user who this proposal would
primarily be aimed at.
But in any event, since you are doing that, your repos will never
accumulate a high enough percentage of loose objects (whatever the
threshold is) to trigger the warning and/or automatic launch. So you can
continue to operate as before, no difference in behavior, while people
who don't know how / want to set up cron jobs will have their
repositories cleaned too.
git-gc can leave behind a "last completed" timestamp and we can suppress
the check for excess loose objects until some minimum amount of time has
passed since last git-gc. If that amount is greater than the interval
between your cron jobs, you won't even get any (measurable) overhead
from the detection to see if the warning is needed.
-Steve