--- /dev/null
+I still don't like repeated name inside each symlink.
+
+I enabled every tunable I found to make it sane for me: ./git/annex/objects/xxx/SHA256-.../SHA256-...
+I expect to have no more than 1.000.000 files which I care about even if I live till 100 years, which nicely fit into performance window of filesystem of 4096 folders with 5000 files each.
+I don't care about readonly files -- I have BTRFS snapshots and weekly backups for the case of unintentional disaster and corruption of some files till SHA don't match anymore.
+I don't care about nice distributed lock-free mechanics of git annex -- I always commit each new annex file as separate commit and don't mess with scripting git write operations in my repo.
+What I care is symlinks length -- to fit into my screen width in terminal file manager, repo performance and underlying git repo size -- all of which are dependent on the length of path till the real file.
+
+What I found reading git-annex forum/todo/bugs and datalad issues for two month -- all are old discussions, ideas and maybe obsolete plans.
+I even found somewhere proposal for single-lock model of working for git-annex.
+
+* https://git-annex.branchable.com/design/new_repo_versions/
+* https://github.com/datalad/datalad/issues/32
+
+Yet what I did not found is the status of the idea to add such tunable to git-annex.
+Deadly unsafe tunable to drop nested SHA-SHA folder would totally satisfy me -- and I would immediately go writing scripts to replay whole my git history onto the freshly initialized git-annex with new symlinks.
+Especially if waiting for "more safe" single-lock git-annex w/o SHA-SHA may take years.
+
+So, what is the status of plans?
+Do you have any idea how many years (or month?) left to wait until the idea will brew enough to become vital and git-annex codebase transforms into more suitable state to implement such tunable?