[Savannah-hackers-public] Re: [sr #107505] Please reduce gnash git repo size

[Jim Meyering]

Sylvain Beucler wrote:
> Hi,
>
> On Sun, Oct 24, 2010 at 11:26:09PM +0200, Jim Meyering wrote:
>> Sylvain Beucler wrote:
>> > Jim,
>> >
>> > Can you have a look at this?
>> >
>> > The gnash repo can be packed from 760M (gc) to 60M (gc --aggressive).
>>
>> Nice! (in a way ;-)
>>
>> > Does that sound normal?  Is there a risk to lose data with it?
>>
>> It is to be expected, if no one has ever run
>> "git gc --aggressive" or an equivalent on this repository before.
>>
>> > If not, should we plan to do it on other repo too?
>>
>> Yes, I think so.  "git gc" documentation suggests to run it
>> "every few hundred change-sets or so".
>>
>> > On Sun, Oct 24, 2010 at 08:14:03PM +0000, Sylvain Beucler wrote:
>> >>
>> >> Follow-up Comment #2, sr #107505 (project administration):
>> >>
>> >> Wow, it's down to 60M after 20mn.
>> >> I'll check with Jim to have an opinion on doing it on the real repo.
>>
>> As far as I know, there is no risk of data loss.
>> I think of "git gc" as coalescing into a new "pack" any free objects,
>> and compressing that resulting new pack.
>> On the other hand, with --aggressive, it examines all objects
>> (including those in previously coalesced packs) and does a global
>> search for common/compressible things.
>>
>> Thus, if you have many separately-packed changes that would have
>> been better compressed if they'd ended up in the same pack,
>> --aggressive will yield significant benefit.
>
> Thanks for the info.
>
> Do you know about concurrency?  I.e. need we make the repo read-only
> for developers when we're doing such a repack?

>From what I recall, that's not necessary.
I think (probably a gross simplification) it creates a big pack of
whatever's on hand, and then flips a ref (atomic rename) to make the new
pack's objects live, and then removes the packed (and now logically
unlinked) objects at its leisure. Any new objects that came in while
packing are simply not packed.