comment
authorJoey Hess <joeyh@joeyh.name>
Mon, 7 Nov 2016 17:32:15 +0000 (13:32 -0400)
committerJoey Hess <joeyh@joeyh.name>
Mon, 7 Nov 2016 17:32:15 +0000 (13:32 -0400)
doc/bugs/unlock_should_warn_if_file_isn__39__t_in_repo/comment_1_4fb6a9aa7cd3b141b2d2f1b4acd2092f._comment [new file with mode: 0644]

diff --git a/doc/bugs/unlock_should_warn_if_file_isn__39__t_in_repo/comment_1_4fb6a9aa7cd3b141b2d2f1b4acd2092f._comment b/doc/bugs/unlock_should_warn_if_file_isn__39__t_in_repo/comment_1_4fb6a9aa7cd3b141b2d2f1b4acd2092f._comment
new file mode 100644 (file)
index 0000000..7fe2096
--- /dev/null
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-11-07T17:25:10Z"
+ content="""
+In general, git-annex silently skips files that are not known to git,
+or are not annexed files. That's what's happening here.
+
+This skipping behavior can sometimes be confusing, if you are not
+familiar with it. But it's also very convenient. For example `git annex
+unlock *` will unlock only annexed files and not complain about any other
+files; `git annex unlock .` will recursively unlock only annexed files and not
+complain about non-annexed files or files that are already unlocked.
+
+In your example, git-annex has no way to tell that the file has been
+renamed; a file that has never been added to git would look the same
+to it as that renamed file.
+"""]]