response

1 files changed, 19 insertions, 2 deletions

diff --git a/doc/bugs/unlock_fails_silently_with_directory_symlinks.mdwn b/doc/bugs/unlock_fails_silently_with_directory_symlinks.mdwn
index 7092a5293..4f6c82300 100644
--- a/doc/bugs/unlock_fails_silently_with_directory_symlinks.mdwn
+++ b/doc/bugs/unlock_fails_silently_with_directory_symlinks.mdwn
@@ -12,8 +12,6 @@ What is the expected output? What do you see instead?
 
 +    I think ```git annex unlock``` should resolve the symlinks and realize that this is a tracked file.
 
-+    Also, I think ```git annex unlock``` should emit an error message if a file explicitly addressed on the commandline can not be acted upon.
-
 What version of git-annex are you using? On what operating system?
 
 +    3.20121112 in debian unstable
@@ -32,3 +30,22 @@ Thank you, thank you!
       - Jason
 
 jason@jasonwoof.com
+
+> I'm afraid this is not a bug. Here's why: If you run "git mv books/foo
+> books/bar", git will complain:
+>
+>> fatal: not under version control, source=books/foo, destination=books/bar
+>
+> So git-annex is just following git's lead (indeed, it's just running
+> `git ls-files` to find files to act on), and git doesn't
+> recognise this path as a file that's in git. --[[Joey]] 
+
++    Also, I think ```git annex unlock``` should emit an error message if a file explicitly addressed on the commandline can not be acted upon.
+
+> I'm beginning to think perhaps it should. Users seem to find the current
+> behavior to be sometimes confusing.
+> 
+> However, it's actually a very difficult change to make. Several commands
+> have multiple seek stages that act on different types of files, so
+> any warning printed by an earlier stage may be premature if a later
+> stage comes along and deals with a file. --[[Joey]]