Apologies if this isn't the right section. I considered posting it at https://git-annex.branchable.com/tips/unlocked_files/ but thought this might be a better place.
### What version of git-annex are you using? On what operating system?
v7
First of all, I want to say that I'm a *HUGE* fan of Joey and git annex. I've been using and following it for 5+ years now, and absolutely love it.
Unfortunately, now for the first time I saw a change that worries me. One of the core tenets of git annex is "future proofing" in a "world that's forgotten git and git annex" and the latest changes go against that. There seems to be a lot of "magic" under the covers with smudge and clean filters, no longer using standard symlinks to identify files and instead relying on smudge filters which would make life without git and git annex _very_ painful.
I understand that this is an improvement over direct mode, but I view direct mode as a crutch only for people/hosts who need it (and I've used it too). I wish the new "unlocked" files behaved the same way. Just because _one_ of my hosts needs a crutch doesn't mean the rest of them (and the git history) all need to have the data identified by a string that relies on git annex internals. /annex/objects/xx isn't too complicated, but this violates the core tenet that got me on board git annex on day 1.
One more concern I have is the fact that "git add" now adds files in this mode, which is just a big no no. Not even lfs does this with all the complicated smudge/clean work it does.
(On a closing note, I want to add that knowing Joey, he's probably thought through all of this and has very valid reasons it was this way.)
TL;DR
Please provide support (or better still enable as default) the following behavior:
2018-12-18 07:22:48 +00:00
2018-12-18 07:21:39 +00:00
* "git add" just adds files to git, not annex
* The v7 unlocked mode stores data in git annex(I mean the git-annex branch), and ideally uses standard mechanism like symlinks to track data, with smudge/clean filters used *only* when necessary. (My guess is that the reason it is this way now is because git probably doesn't like doing a type change of a file)
