From 503abb6d54758d36f22585f7db468bbe993c4073 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Wed, 15 Apr 2020 14:25:33 -0400 Subject: [PATCH] remove warning about git gc for annex.alwayscommit=false I doubt that warning has ever been right, but I'm sure it is not right now. For there to be a risk of git gc deleting objects that are in the annex index, journal files would have to be staged into it, and deleted, but the index not committed to the git-annex branch. And AFAICS, there is no code path where that actually happens. I considered adding one recently, but didn't. The way it actually works is, as long as the user has annex.alwayscommit=false the data lives in the journal, where it's safe from git gc. Then when git-annex is run w/o that config, the journal is staged into the index, which is immediately committed to the branch. There's no window where git gc could delete the objects, because git gc only deletes objects after some time (2 weeks by default). Now, if git-annex gets suspended at just the wrong time, or interrupted, then yes, it's possible. But doesn't matter whether that config was ever set or not. And many uses of git-annex also recover from that situation by committing to the git-annex branch. --- doc/git-annex.mdwn | 4 ---- 1 file changed, 4 deletions(-) diff --git a/doc/git-annex.mdwn b/doc/git-annex.mdwn index e1545523f0..5f7d9a95fd 100644 --- a/doc/git-annex.mdwn +++ b/doc/git-annex.mdwn @@ -1039,10 +1039,6 @@ Like other git commands, git-annex is configured via `.git/config`. commit the data by running `git annex merge` (or by automatic merges) or `git annex sync`. - You should beware running `git gc` when using this configuration, - since it could garbage collect objects that are staged in git-annex's - index but not yet committed. - * `annex.commitmessage` When git-annex updates the git-annex branch, it usually makes up