Reduce transfer.unpacklimit in gitconfig
Summary
Following https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/313 which @jacobvosmaer-gitlab proposed 3 years ago, it seems like setting transfer.unpacklimit
in gitconfig will help improve the overall git pull/push operation.
As you dont unpack objects every push -> receive-pack, you write less files on disk and thus improve the overall user experience for faster pull/push.
To quote official git config documentation
receive.unpackLimit
If the number of objects received in a push is below this limit then the objects will be unpacked into loose object files.
However if the number of received objects equals or exceeds this limit then the received pack will be stored as a pack, after adding any missing delta bases.
Storing the pack from a push can make the push operation complete faster, especially on slow filesystems.
If not set, the value of transfer.unpackLimit is used instead.
Its worth to note that the issue blocked this 3 years ago mostly was due to rugged activities, based on ruby gem, which is based on libgit2, is now mostly irrelevant as git activities are being handle via gitaly directly.
Proposal
- Set
transfer.unpacklimit = 1
as default omnibus config.
Potential impact
Back end git storage will rely heavily on scheduled git repack
to re-pack objects in a more optimized manner.
Which instance admin could opt-out in Housekeeping settings.