Added a comment
authorkyle <kyle@web>
Thu, 1 Oct 2020 19:07:48 +0000 (19:07 +0000)
committeradmin <admin@branchable.com>
Thu, 1 Oct 2020 19:07:48 +0000 (19:07 +0000)
doc/todo/clarify_that_v7_applies_to_all_clones/comment_5_e0fc732a977dafe2644635d47e153495._comment [new file with mode: 0644]

diff --git a/doc/todo/clarify_that_v7_applies_to_all_clones/comment_5_e0fc732a977dafe2644635d47e153495._comment b/doc/todo/clarify_that_v7_applies_to_all_clones/comment_5_e0fc732a977dafe2644635d47e153495._comment
new file mode 100644 (file)
index 0000000..a854c52
--- /dev/null
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 5"
+ date="2020-10-01T19:07:45Z"
+ content="""
+> What is the most efficient way to identify if there are unlocked
+> files in the tree (or full repository)?
+
+I can't say anything about efficiency, but FWIW with git-annex
+7.20191009 or later there's an `--unlocked` matching item, so you can
+say `git annex find --unlocked`.  Since you're working in the context
+of repos that have already been upgraded, I think you could use that
+to find unlocked files in the working tree.
+
+As for outside of the working tree, `find` takes a `--branch`
+argument, but, as far as I can tell, that doesn't match anything when
+combined with `--unlocked` (tried with 8.20200908).  However, I'm not
+sure you'd need to consider anything other than the working tree.  If
+all of these repos were v5 before, then an unlocked file could have
+only been in an uncommitted state, so I don't see how it'd end on
+another ref without committing/switching branches afterwards.
+
+"""]]