From 1aa7082c9a8a7e2b3321fc4d1661d460d5cb1f7e Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Wed, 15 Apr 2020 12:17:57 -0400 Subject: [PATCH] better response --- ...ent_1_793ab4d52a3a4a3a30b0e72b72ac18eb._comment | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/doc/bugs/commits_created_despite_alwayscommit__61__false_as_of_recent_change/comment_1_793ab4d52a3a4a3a30b0e72b72ac18eb._comment b/doc/bugs/commits_created_despite_alwayscommit__61__false_as_of_recent_change/comment_1_793ab4d52a3a4a3a30b0e72b72ac18eb._comment index 69e6acea39..2189ebbf0a 100644 --- a/doc/bugs/commits_created_despite_alwayscommit__61__false_as_of_recent_change/comment_1_793ab4d52a3a4a3a30b0e72b72ac18eb._comment +++ b/doc/bugs/commits_created_despite_alwayscommit__61__false_as_of_recent_change/comment_1_793ab4d52a3a4a3a30b0e72b72ac18eb._comment @@ -4,13 +4,15 @@ date="2020-04-15T16:09:02Z" content=""" 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. -The only way to fix this, I think, is to disable the entire optimisation -when annex.alwayscommit is false and the journal is dirty. +The right fix, I think is to avoid making a commit, and instead only stage +the journal files into the annex index. -Or hmm, it should not be a problem for it to stage the journal files to the -index, but not commit the index. Not clear to me why it would be committing -even after that change, so I'll investigate that first. +But probably only when annex.alwayscommit=false and still commit when it's +true, because leaving staged changes in the annex index without +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. """]]