Junio C Hamano <gitster@xxxxxxxxx> writes:
> Sivakumar Selvam <gerritcode@xxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html