From 82ba8c9a6a949c9f3677f60c680a7c6826a9869b Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 12 Oct 2015 13:29:00 -0400 Subject: [PATCH] comment --- ..._ef1dbde0fbf20b7fd91503d9df50dcab._comment | 33 +++++++++++++++++++ 1 file changed, 33 insertions(+) create mode 100644 doc/todo/wishlist:_allow_re-adding_without_generating_log_entry/comment_1_ef1dbde0fbf20b7fd91503d9df50dcab._comment diff --git a/doc/todo/wishlist:_allow_re-adding_without_generating_log_entry/comment_1_ef1dbde0fbf20b7fd91503d9df50dcab._comment b/doc/todo/wishlist:_allow_re-adding_without_generating_log_entry/comment_1_ef1dbde0fbf20b7fd91503d9df50dcab._comment new file mode 100644 index 0000000000..3c6df04770 --- /dev/null +++ b/doc/todo/wishlist:_allow_re-adding_without_generating_log_entry/comment_1_ef1dbde0fbf20b7fd91503d9df50dcab._comment @@ -0,0 +1,33 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2015-10-12T17:17:12Z" + content=""" +I want to think a little bit about why the location log is updated in this +case before thinking about adding an option. It might make sense to just +not update the location log when it already says the file is present and +only the timestamp is being changed. + +I can think of 2 reasons not to do it: + +1. If it has to query the current state of the log, that might slow down + `git annex add` in the common case, just for this less common case. + + But, updating the log necessarily involves reading it in and outputting + an updated one, so that could probably be finessed. + + (Or, git annex add makes a separate pass to add unlocked files anyway, + so it could only do the query in that case.) + +2. There might be good reasons to want to update the timestamp in the log, + since it's just verified that the content is still present. Maybe. + + But then, fsck doesn't update the timestamps when it does the same kind + of verification. And, the only thing that updates a given repo's entry + in the log is that repo, or another repo that is sending or dropping + content from that repo. + + There don't seem to be any reasons of + distributed consistency to need to worry about updating the timestamp + just to reflect current facts. +"""]]