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.
This commit is contained in:
parent
ddadc0c1aa
commit
503abb6d54
1 changed files with 0 additions and 4 deletions
|
@ -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
|
||||
|
|
Loading…
Reference in a new issue