By the analogy with the maxtime and maxmount in the ext3 when it
reminds you to fsck, when number of mounts since last fsck, or time since
last fsck is above some limits. I think this makes practical sense. I think
the similar thing makes sense wrt to 'git gc'.
Is it possible that git repo had a parameter N, and when the counter of
unpacked object hit this number, then git operations start to print
semi-annoying warnings
"Time to optimize your repo using 'git gc' command ... "
?
I am naive user. I forget things. Really. I rely on git to remember things.
Is this a reasonable parameter ?
Thanks
Yakov
Yakov Lerner wrote:
By the analogy with the maxtime and maxmount in the ext3 when it
reminds you to fsck, when number of mounts since last fsck, or time since
last fsck is above some limits. I think this makes practical sense. I
think
the similar thing makes sense wrt to 'git gc'.
Is it possible that git repo had a parameter N, and when the counter of
unpacked object hit this number, then git operations start to print
semi-annoying warnings
"Time to optimize your repo using 'git gc' command ... "
?
I also wrote a commit hook that counts loose objects and just runs
repack with differing parameters. Check for threads with terms
"generational repack" in them.
To make it a really fast check, Linus suggested estimating the number of
loose objects with a sample, eg if the threshold is 256 loose objects
and you find 3 or more objects in directories 01, 02, and 03 then it's
time to repack.
I've been using the script I posted on my own repositories for a while
and was never really annoyed by the 2-3s aside it took every few dozen
commits to repack. But then I'm probably biased and usually playing on
relatively zippy machines.
Sam.