From f73667dda55924978df1e5d687dee8e54671fbba Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Mon, 2 Dec 2013 20:35:49 +0000 Subject: [PATCH] Added a comment --- ...comment_4_5ac5a10bdddf23153e8ea0a8eb60323e._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/bugs/incremental_fsck_should_not_use_sticky_bit/comment_4_5ac5a10bdddf23153e8ea0a8eb60323e._comment diff --git a/doc/bugs/incremental_fsck_should_not_use_sticky_bit/comment_4_5ac5a10bdddf23153e8ea0a8eb60323e._comment b/doc/bugs/incremental_fsck_should_not_use_sticky_bit/comment_4_5ac5a10bdddf23153e8ea0a8eb60323e._comment new file mode 100644 index 0000000000..3b55891c4f --- /dev/null +++ b/doc/bugs/incremental_fsck_should_not_use_sticky_bit/comment_4_5ac5a10bdddf23153e8ea0a8eb60323e._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.64" + subject="comment 4" + date="2013-12-02T20:35:45Z" + content=""" +@helmut Well, true, it could overwrite the old ref with a new one at the start of a new fsck pass. If there was a separate ref for each uuid, this would work even for mixed local/remote fscking. And git should eventually drop the objects associated with the old ref, probably in `gc --auto`, which has a default --prune of 2 weeks. + +The git overhead would probably be fine for fsck. I am less sure about it for the direct mode mapping files, which can be queried quite frequently. In particular inAnnex is used lots of places, often repeatedly on a lot of files, and it uses withObjectLoc, which uses associatedFiles. +"""]]