tuninggit-annexhttp://git-annex.branchable.com/tuning/git-annexikiwiki2024-03-06T12:26:56Zannex.tune.objecthashlower=true is not just "lower" letters used but a different strategy altogetherhttp://git-annex.branchable.com/tuning/comment_1_f8af8e9b696d32d238ebd56a3b8058c4/Yaroslav2015-02-01T02:58:26Z2015-02-01T02:58:26Z
<p>it starts to use 2 levels (even if annex.tune.objecthash1=true) of hash directories having 3 characters in the filename at each level. So it is not just "taken existing hash directories (1 or 2 levels) and use their lower-case version. It is a different way to create the hash directories:</p>
<p>e.g. one with objecthas1=true</p>
<p>1 -> .git/annex/objects/qj/SHA256E-s6--ecdc5536f73bdae8816f0ea40726ef5e9b810d914493075903bb90623d97b1d8/SHA256E-s6--ecdc5536f73bdae8816f0ea40726ef5e9b810d914493075903bb90623d97b1d8</p>
<p>and if I provide all three options at once:</p>
<p>1 -> .git/annex/objects/ccf/a40/SHA256E-s6--ecdc5536f73bdae8816f0ea40726ef5e9b810d914493075903bb90623d97b1d8/SHA256E-s6--ecdc5536f73bdae8816f0ea40726ef5e9b810d914493075903bb90623d97b1d8</p>
comment 2http://git-annex.branchable.com/tuning/comment_2_a0091dbb39b79dfe101d05f9a5db216f/joey2015-02-04T19:01:25Z2015-02-04T17:09:41Z
<p>Right, it's not simply lower-casing but a different hash strategy
as described in <a href="http://git-annex.branchable.com/internals/hashing/">hashing</a>.</p>
<p>Combining annex.tune.objecthashlower and annex.tune.objecthash1 will
result in one level of hash directories. If you get two levels then
you probabaly typoed "objecthas1" ...</p>
Syncing between untuned and tuned repo?http://git-annex.branchable.com/tuning/comment_4_5b782975263480a405c5e8dcfe058007/stephane-gourichon-lpad2017-07-18T11:49:10Z2017-07-18T11:49:10Z
<blockquote><p>Also, it's not safe to merge two separate git repositories that have been tuned differently (or one tuned and the other one not). git-annex will prevent merging their git-annex branches together, but it cannot prevent git merge remote/master merging two branches, and the result will be ugly at best (git annex fix can fix up the mess somewhat).</p></blockquote>
<p>My main use repo is 1.7TB large and holds 172.000+ annexed files.
Variations in filename case has lead to a number of file duplications that are still not solved (I have base scripts that can be used to flatten filename case and fix references in other files, but it will probably mean handling some corner cases and there are more urgent matters for now).</p>
<p>For these reasons I'm highly interested in the lowercase option and I'm probably not the only one in a similar case.</p>
<p>Does migrating to a tuned repository mean unannexing everything and reimporting into a newly created annex, replica by replica then sync again? That's a high price in some setup. Or is there a way to somehow <code>git annex sync</code> between a newly created repo and an old, untuned one?</p>
comment 4http://git-annex.branchable.com/tuning/comment_4_1c576f9a5e0a0b5d7d8edf9d40462874/joey2017-08-28T17:41:28Z2017-08-28T17:40:06Z
<p>It should be possible to write a <code>git-filter-branch</code> that converts
a repository from one tuning to aonther, but it would not be trivial, and
noone has done it yet. You'd still have to run it in every clone of the
repository. Tuned and non-tuned repositories can't interoperate.</p>
Still experimental?http://git-annex.branchable.com/tuning/comment_5_0143b798e75ad25c5917794a49a879fb/imlew2024-03-06T12:26:56Z2024-03-06T12:26:56Z
<p><code>annex.tune.objecthash1=true</code> and <code>annex.tune.branchhash1=true</code> seem like they could be helpful in reducing git annex's inode usage, but the disclaimer about this feature being experimental is a little worrying.</p>
<p>Since this it is over 10 years old though, is it still considered experimental or has it graduated to being a stable feature? I.e. will using this meaningfully increase the chance of losing data?</p>
<p>Also, what is the (potential) benefit of using lowercase for the hashes?</p>