From 8ac44498d69dfe968d158e75a7bc032e7a8ce83f Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Wed, 15 Apr 2020 12:43:22 -0400 Subject: [PATCH] comment --- ..._1c0e6f07f1da2872455401ac97c4ccc8._comment | 36 +++++++++++++++++++ 1 file changed, 36 insertions(+) create mode 100644 doc/bugs/commits_created_despite_alwayscommit__61__false_as_of_recent_change/comment_2_1c0e6f07f1da2872455401ac97c4ccc8._comment diff --git a/doc/bugs/commits_created_despite_alwayscommit__61__false_as_of_recent_change/comment_2_1c0e6f07f1da2872455401ac97c4ccc8._comment b/doc/bugs/commits_created_despite_alwayscommit__61__false_as_of_recent_change/comment_2_1c0e6f07f1da2872455401ac97c4ccc8._comment new file mode 100644 index 0000000000..d392fde7a4 --- /dev/null +++ b/doc/bugs/commits_created_despite_alwayscommit__61__false_as_of_recent_change/comment_2_1c0e6f07f1da2872455401ac97c4ccc8._comment @@ -0,0 +1,36 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 2""" + date="2020-04-15T16:30:43Z" + content=""" +Tried to implement that approach, but it has a problem: Once the journal +gets staged into the index, the journal is no longer dirty. So, when +git-annex is later run with annex.alwayscommit=true, it won't know it needs +to commit the index to the branch. It would only do so after some other +subsequent change is made. So `git annex merge` would not commit the staged +changes as it does now. + +Solving that would need some other indication that the index has staged +changes in it, eg a flag file or some comparison of index file timestamp +with the git-annex branch ref timestamp. But whatever it is would need to +be checked for when annex.alwayscommit=true. So git-annex would become +slower in the common case to support annex.alwayscommit=false. + +The slowdown would be much less than the win of the optimisation that +caused this, but still I am not much of a fan of slowing things back down +for an uncommon case. + +(The only way around that, maybe, would be to leave a file in the journal +after staging it, so git-annex treats the journal as dirty without needing +to check anything else, and so knows it needs to commit the annex index +later. But then the journal would be treated as dirty every time git-annex +starts up, and so would be staged into the index. Which would make running +with annex.alwayscommit=false slower. Maybe the file could have a special +name that git-annex knows it does not need to stage? This feels like a lot +of complexity being added.) + +So, I'm now leaning more toward disabling the optimisation when +annex.alwayscommit=false. The journal won't be staged to the index +then, and git-annex will have to check for journalled changes as long +as it's running with that configuration. No worse than it was before. +"""]] -- 2.30.2