Re: [lmi] Incidental differences on first commit and push of 2019

[Vadim Zeitlin]

On Wed, 9 Jan 2019 21:10:05 +0000 Greg Chicares <address@hidden> wrote:

GC> I've done so, just because this seems like a good time for routine
GC> maintenance. Summarizing:
GC> 
GC>   yours  mine  scenario
GC>    125M   33M  initial condition*
GC>     23M   20M  after explicit 'git gc'
GC>     ---   17M  after explicit 'git gc --aggressive'
GC> 
GC> * My initial figure comes just a day or two after the previously
GC>   reported "Auto packing the repository" event.

 To fill in the blanks (the dashes?), size of my .git after aggressive
garbage collection is 21M.

GC> Notably, 'git gc' doesn't result in exactly the same size for us both.

 This is to be expected, as I have a few branches and a couple of things in
stash.

GC> The '--aggressive' command took less than a minute (I didn't think to
GC> measure exactly how long it took). I can't recall ever using '--aggressive'
GC> before, but maybe I should do it at the beginning of each year:
GC> 
GC> https://git-scm.com/docs/git-gc
GC> |  --aggressive ... The effects of this optimization are persistent, so this
GC> | option only needs to be used occasionally; every few hundred changesets 
or so.

 FWIW, I had a vague memory of an advice not to use this option, but
checking it now I see that it's obsolete and that while Linus did advise
exactly this, it was in 2007 and the implementation of the option has
changed since then to avoid the problems he pointed out. git-repack might
still result in even smaller repository size but I just don't care enough
about size savings, especially for repositories of such relatively small
size, to use it. Of course, for the large repositories where these savings
could be worth having, running all these commands takes a much longer time,
so I'm not sure what the moral is here, other than "buy bigger SSDs".

 Regards,
VZ