diff options
author | 2012-11-25 15:59:03 -0400 | |
---|---|---|
committer | 2012-11-25 15:59:03 -0400 | |
commit | 3c1d0f12a6b1cb575979a56daadab52d3f4968b6 (patch) | |
tree | e593384e7efffdab9d610a851eb038aa79093b62 /doc/bugs/unlock_fails_silently_with_directory_symlinks.mdwn | |
parent | d1433a155834a2f2c963a6d54a896ee8f9dac6f3 (diff) |
response
Diffstat (limited to 'doc/bugs/unlock_fails_silently_with_directory_symlinks.mdwn')
-rw-r--r-- | doc/bugs/unlock_fails_silently_with_directory_symlinks.mdwn | 21 |
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]] |