forum/Reverse index key to list of file pathsgit-annexhttp://git-annex.branchable.com/forum/Reverse_index_key_to_list_of_file_paths/git-annexikiwiki2021-03-02T22:09:45Zcomment 1http://git-annex.branchable.com/forum/Reverse_index_key_to_list_of_file_paths/comment_1_acae766349a036040a03e75fa8ed34c6/joey2021-03-02T22:09:45Z2021-01-04T15:58:24Z
<blockquote><p>How would I make sure that potential moves/renames will update the index?</p></blockquote>
<p>If I had a good answer to that question I would have built it already.</p>
<p>I mean, a post-commit hook can notice changed after the fact, but noticing
them when they've just been staged is harder.</p>
<p>It does not make sense to store such an index in the git-annex branch,
because it's redundant information to what's already stored in git trees.</p>
<p>This is discussed in <a href="http://git-annex.branchable.com/todo/cache_key_info/">cache key info</a>.</p>
comment 2http://git-annex.branchable.com/forum/Reverse_index_key_to_list_of_file_paths/comment_2_716efb07d216d9a063bb9498c8e76ea1/AlbertZeyer2021-03-02T22:09:45Z2021-01-06T11:15:42Z
<p>Thanks for the answer.</p>
<p>How does <code>git status</code> checks for changes? I feel it is quite fast at that.</p>
<p>So you could update the persistent database by post-commit hook, and have a temporary virtual overlay when used which takes current staged changes also into account. And maybe you can also add a <code>--fast</code> option, which would skip this part, because the user probably knows when to expect staged changes.</p>
<p>I think this would be pretty useful. This would also change somewhat the whole way how I would use the Annex. I expect that I have this case quite often, that some file content is referenced from multiple file paths.</p>
comment 3http://git-annex.branchable.com/forum/Reverse_index_key_to_list_of_file_paths/comment_3_6b75bd75623004f05f609a39e95250ab/nguenthe2021-03-02T22:09:45Z2021-02-09T17:06:24Z
<p>I just figured this out today!</p>
<p>In v8 repos, every annexed file gets replaced by a text string like this:</p>
<pre><code>+/annex/objects/SHA256E-s320029--488e29f5584ba4e474db95aa42fbb58ddb92f2a59bc0b24a91171acb4d8f4828.png
</code></pre>
<p>((</p>
<p>you can see them with <code>git log -p</code> or</p>
<pre><code>$ git show HEAD:vlcsnap-2019-03-22-03h42m47s659.png
/annex/objects/SHA256E-s320029--488e29f5584ba4e474db95aa42fbb58ddb92f2a59bc0b24a91171acb4d8f4828.png
</code></pre>
<p>))</p>
<p>So to get the reverse pointer, you can use <code>git grep</code>:</p>
<pre><code>$ git grep SHA256E-s320029--488e29f5584ba4e474db95aa42fbb58ddb92f2a59bc0b24a91171acb4d8f4828.png HEAD
HEAD:vlcsnap-2019-03-22-03h42m47s659.png:/annex/objects/SHA256E-s320029--488e29f5584ba4e474db95aa42fbb58ddb92f2a59bc0b24a91171acb4d8f4828.png
</code></pre>
comment 4http://git-annex.branchable.com/forum/Reverse_index_key_to_list_of_file_paths/comment_4_e54268d93837b3b8e216ec6af074f3c6/nguenthe2021-03-02T22:09:45Z2021-02-09T17:09:15Z
<code>git grep</code> might be just as slow as <code>find</code> in the end, but so far it has always been very fast for me. Maybe I just don't have a hyper-huge number of files.
comment 5http://git-annex.branchable.com/forum/Reverse_index_key_to_list_of_file_paths/comment_5_022728be6cd3ac168a74d16baf29c0e1/joey2021-03-02T22:09:45Z2021-02-15T17:25:05Z
<p>git grep doesn't use an index per se, but is probably faster
than <code>find</code> at least sometimes. And probably somewhat faster than things
involving <code>git-annex find</code> too.</p>
<p>It's unfortunate that <code>git grep</code> doesn't search on the content of symlink
texts, so that can't be used to find locked files.</p>
<p>The equivilant using git-annex find, which will find both types:</p>
<pre><code>git annex find --format '${key}\n' | grep SHA256E-s320029--488e29f5584ba4e474db95aa42fbb58ddb92f2a59bc0b24a91171acb4d8f4828.png
</code></pre>