Re: git repack command on larger pack file

> Junio C Hamano <gitster@pobox.com> writes:
>
>> Sivakumar Selvam <gerritcode@gmail.com> writes:
>>
>>> ... So
>>> I thought of splitting the pack file into 4 GB chunks.
>> ...
>> Hmmm, what is "this issue"?  I do not see anything surprising.
>
> While the explanation might have been enlightening, the knowledge
> conveyed by the explanation by itself would not be of much practical
> use, and enlightment without practical use is never fun.
>
> So let's do another tangent that may be more useful.
>
> In many repositories, older parts of the history often hold the bulk
> of objects that do not change, and it is wasteful to repack them
> over and over.  If your project is at around v40.0 today, and it was
> at around v36.0 6 months ago, for example, you may want to pack
> everything that happened before v36.0 into a single pack just once,
> pack them really well, and have your "repack" not touch that old
> part of the history.
>
>  $ git rev-list --objects v36.0 |
>    git pack-objects --window=200 --depth=128 pack
>
> would produce such a pack [*1*]
>
> The standard output from the above pipeline will give you a 40-hex
> string (e.g. 51c472761b4690a331c02c90ec364e47cca1b3ac, call it
> $HEX), and in the current directory you will find two files,
> pack-$HEX.pack and pack-$HEX.idx.
>
> You can then do this:
>
>  $ echo "v36.0 with W/D 200/128" >pack-$HEX.keep
>  $ mv pack-$HEX.* .git/objects/pack/.
>  $ git repack -a -d
>
> A pack that has an accompanying .keep file is excempt from
> repacking, so once you do this, your future "git repack" will only
> repack objects that are not in the kept packs.
>

>
>
> [Footnote]
>
> *1* I won't say 200/128 gives you a good pack; you would need to
> experiment.  In general, larger depth will result in smaller pack
> but it will result in bigger overhead while you use the repository
> every day.  Larger window will spend a lot of cycles while packing,
> but will result in a smaller pack.
> --