From 742ce7ec87f570a5d2204315a6540a1aa5d78be7 Mon Sep 17 00:00:00 2001 From: kyle Date: Thu, 1 Oct 2020 19:07:48 +0000 Subject: [PATCH] Added a comment --- ..._e0fc732a977dafe2644635d47e153495._comment | 24 +++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 doc/todo/clarify_that_v7_applies_to_all_clones/comment_5_e0fc732a977dafe2644635d47e153495._comment 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 index 0000000000..a854c52519 --- /dev/null +++ b/doc/todo/clarify_that_v7_applies_to_all_clones/comment_5_e0fc732a977dafe2644635d47e153495._comment @@ -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. + +"""]]