Added a comment
This commit is contained in:
parent
1bf55a8fc1
commit
742ce7ec87
1 changed files with 24 additions and 0 deletions
|
@ -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.
|
||||||
|
|
||||||
|
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue