summaryrefslogtreecommitdiff
path: root/Documentation/RelNotes/2.2.0.txt
diff options
context:
space:
mode:
authorLibravatar David Turner <dturner@twosigma.com>2017-04-20 16:41:18 -0400
committerLibravatar Junio C Hamano <gitster@pobox.com>2017-04-20 22:06:00 -0700
commitbe4ca290570f9173db64ea1f925b5b3831c6efed (patch)
tree3c010d3574792fba13c5b6a2c177dfb01c628705 /Documentation/RelNotes/2.2.0.txt
parentGit 2.13-rc0 (diff)
downloadtgif-be4ca290570f9173db64ea1f925b5b3831c6efed.tar.xz
Increase core.packedGitLimit
When core.packedGitLimit is exceeded, git will close packs. If there is a repack operation going on in parallel with a fetch, the fetch might open a pack, and then be forced to close it due to packedGitLimit being hit. The repack could then delete the pack out from under the fetch, causing the fetch to fail. Increase core.packedGitLimit's default value to prevent this. On current 64-bit x86_64 machines, 48 bits of address space are available. It appears that 64-bit ARM machines have no standard amount of address space (that is, it varies by manufacturer), and IA64 and POWER machines have the full 64 bits. So 48 bits is the only limit that we can reasonably care about. We reserve a few bits of the 48-bit address space for the kernel's use (this is not strictly necessary, but it's better to be safe), and use up to the remaining 45. No git repository will be anywhere near this large any time soon, so this should prevent the failure. Helped-by: Jeff King <peff@peff.net> Signed-off-by: David Turner <dturner@twosigma.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'Documentation/RelNotes/2.2.0.txt')
0 files changed, 0 insertions, 0 deletions