update

diff --git a/doc/todo/speed_up_annex.adjustedbranchrefresh.mdwn b/doc/todo/speed_up_annex.adjustedbranchrefresh.mdwn
index 4898011540294bb9b4ddddeedcb0e9c7101204e4..7f53438816d338375d1e21cffc96347232770dd4 100644 (file)
--- a/doc/todo/speed_up_annex.adjustedbranchrefresh.mdwn
+++ b/doc/todo/speed_up_annex.adjustedbranchrefresh.mdwn
@@ -1,26 +1,19 @@
 The --hide-missing and --unlock-present adjusted branches
 depend on whether the content of a file is present. So after a get or drop,
-the branch needs to be updated to reflect the change. Currently this has to
-be done manually, except git-annex sync does do it at the end. Can the
-update be automated?
-
-Of course, it could be updated on shutdown whenever content was transferred
-or dropped. The question really is, can it be done efficiently enough that
-it makes sense to do that? And for that matter, can it be done efficiently
-enough to do it more frequently? After every file or after some number of
-files, or after processing all files in a (sub-)tree?
-
-> Since the answer to that will change over time, let's make a config for
-> it. annex.adjustedbranchrefresh
-> 
-> The config can start out as a range from 0 up that indicates how
-> infrequently to update the branch for this. With 0 being never refresh,
-> 1 being refresh the minimum (once at shutdown), 2 being refresh after 
-> 1 file, 100 after every 99 files, etc.
-> If refreshing gets twice as fast, divide the numbers by two, etc.
-> If it becomes sufficiently fast that the overhead doesn't matter,
-> it can change to a simple boolean. Since 0 is false and > 0 is true,
-> in git config, the old values will still work. (done)
+the branch needs to be updated to reflect the change. 
+
+To avoid the user needing to do it manually, the 
+annex.adjustedbranchrefresh config automates it now. That is not yet
+enabled by default, because it can be slow. 
+
+Can it be done efficiently enough to become default?
+And how frequently can it update without being too slow?
+After every file or after some number of files, or after processing
+all files in a (sub-)tree, or only once at the end of a command?
+
+The config was designed as a numeric scale with the hope that it might
+later become a simple boolean if it got fast enough. Since 0 is false
+and > 0 is true, in git config, the old values will still work.
 
 Investigation of the obvious things that make it slow follows: