From b241f579c0d922c68e709cde5f49d76a7e3b14bd Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Wed, 15 Apr 2020 12:14:39 -0400 Subject: [PATCH] hm --- .../comment_1_793ab4d52a3a4a3a30b0e72b72ac18eb._comment | 4 ++++ 1 file changed, 4 insertions(+) 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 056bea52ce..69e6acea39 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 @@ -9,4 +9,8 @@ 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. + +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. """]] -- 2.30.2