'git gc' & number of unpacked objects ?

Yakov Lerner· Jul 17, 2007, 16:14 UTC · lore

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

Sam Vilain· Jul 17, 2007, 20:57 UTC · re: Yakov Lerner · lore

Re: 'git gc' & number of unpacked objects ?

Yakov Lerner wrote:

Show 11 quoted lines

> 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.