From 3c1d0f12a6b1cb575979a56daadab52d3f4968b6 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sun, 25 Nov 2012 15:59:03 -0400 Subject: response --- ...lock_fails_silently_with_directory_symlinks.mdwn | 21 +++++++++++++++++++-- 1 file 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]] -- cgit v1.2.3