Merge branch 'master' of ssh://git-annex.branchable.com

1 files changed, 10 insertions, 0 deletions

diff --git a/doc/bugs/git_annex_won__39__t_copy_files_to_my_usb_drive/comment_7_b101fab9e690d1b335a1a29abab68d6c._comment b/doc/bugs/git_annex_won__39__t_copy_files_to_my_usb_drive/comment_7_b101fab9e690d1b335a1a29abab68d6c._comment
new file mode 100644
index 000000000..178b62fa7
--- /dev/null
+++ b/doc/bugs/git_annex_won__39__t_copy_files_to_my_usb_drive/comment_7_b101fab9e690d1b335a1a29abab68d6c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.210"
+ subject="comment 7"
+ date="2013-02-26T18:41:57Z"
+ content="""
+Getting back to the original problem, it seemed to be that the remote already had the files, but the local location log was not aware of this. Perhaps because the remote got the files from somewhere else and `git annex sync` or similar had not been run to get that into into the local repo recently? Anyway, copying files to the remote was correctly detected to be unnecessary.
+
+Currently, when that happens, it does not update the local location log. That is a change made fairly recently, in 40df26757a61d4f057bcbf38cd5fe949d1c9be95, as a kind of optimisation -- I'd seen it updating the location log during mass copies when it didn't need to, which just bloats `.git`. Seems that optimisation went too far: It should avoid updating the location log when it was correct, but if the location log is wrong, it should optimistically update it.
+"""]]