better response
This commit is contained in:
parent
b241f579c0
commit
1aa7082c9a
1 changed files with 8 additions and 6 deletions
|
@ -4,13 +4,15 @@
|
||||||
date="2020-04-15T16:09:02Z"
|
date="2020-04-15T16:09:02Z"
|
||||||
content="""
|
content="""
|
||||||
That change would lead to buggy behavior, because git-annex would then not
|
That change would lead to buggy behavior, because git-annex would then not
|
||||||
commit the journal files, and the optimisation prevents it reading the
|
stage the journal files, and the optimisation prevents it reading the
|
||||||
journal files, so it would operate with out of date information.
|
journal files, so it would operate with out of date information.
|
||||||
|
|
||||||
The only way to fix this, I think, is to disable the entire optimisation
|
The right fix, I think is to avoid making a commit, and instead only stage
|
||||||
when annex.alwayscommit is false and the journal is dirty.
|
the journal files into the annex index.
|
||||||
|
|
||||||
Or hmm, it should not be a problem for it to stage the journal files to the
|
But probably only when annex.alwayscommit=false and still commit when it's
|
||||||
index, but not commit the index. Not clear to me why it would be committing
|
true, because leaving staged changes in the annex index without
|
||||||
even after that change, so I'll investigate that first.
|
committing them risks git gc deleting the objects used, which is a
|
||||||
|
documented gotcha with annex.alwayscommit=false but not something users
|
||||||
|
should otherwise need to worry about.
|
||||||
"""]]
|
"""]]
|
||||||
|
|
Loading…
Reference in a new issue