summaryrefslogtreecommitdiff
path: root/builtin/add.c
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2016-06-13 00:36:28 -0400
committerLibravatar Junio C Hamano <gitster@pobox.com>2016-06-14 13:57:42 -0700
commit905f27b86ac1f50c6870a064c3b5b9d82c97a145 (patch)
treefa634994e9cc09c9c326c83d593cf6444e39c80e /builtin/add.c
parentrepack: document --unpack-unreachable option (diff)
downloadtgif-905f27b86ac1f50c6870a064c3b5b9d82c97a145.tar.xz
repack: add --keep-unreachable option
The usual way to do a full repack (and what is done by git-gc) is to run "repack -Ad --unpack-unreachable=<when>", which will loosen any unreachable objects newer than "<when>", and drop any older ones. This is a safer alternative to "repack -ad", because "<when>" becomes a grace period during which we will not drop any new objects that are about to be referenced. However, it isn't perfectly safe. It's always possible that a process is about to reference an old object. Even if that process were to take care to update the timestamp on the object, there is no atomicity with a simultaneously running "repack" process. So while unlikely, there is a small race wherein we may drop an object that is in the process of being referenced. If you do automated repacking on a large number of active repositories, you may hit it eventually, and the result is a corrupted repository. It would be nice to fix that race in the long run, but it's complicated. In the meantime, there is a much simpler strategy for automated repository maintenance: do not drop objects at all. We already have a "--keep-unreachable" option in pack-objects; we just need to plumb it through from git-repack. Note that this _isn't_ plumbed through from git-gc, so at this point it's strictly a tool for people doing their own advanced repository maintenance strategy. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'builtin/add.c')
0 files changed, 0 insertions, 0 deletions