I have following usecase:
I want to use a central repos for xbmc/kodi where I can play and delete files from kodi somethimes also with a random file manager. But I normaly if a file gets deleted and synced with git annex sync it deletes the file "head" in every repository.
I would like if its only a git annex drop of the content, if thats was the last copy ok then its ok for me that its gone. But if its not the last copy it shhould just delete it from this repo but not delete the heads of the other repositories.
I know that the actual file is still in the other repositories but the entry is gone, I would love if it would be more like a git annex drop instead of a git rm.
Can I do that with setting this repos readonly or is my usecase not supported/doable with git annex?
One way to do this is to switch to a different branch. Then, deletion of a file won't propigate to other repositories, that don't have that same branch checked out.
Or, see http://git-annex.branchable.com/tips/file_manager_integration/ -- file managers can be taught to run
git annex droprather than deleting files. Perhaps xbmc/kodi could be too..Hacked together a small line that would convert my deletion to a annex drop, would be needed to be used in a cronjob or something like that:
git st -s | grep "^ D .*" | tee >(git checkout --
grep -oE "\S*$") >(git annex dropgrep -oE "\S*$")I guess it works only in indirect mode, maybe a git annex fsck before it would be good? (adding --force to the drop command would be good too I think)
So either I rethink my usecase, maybe its ok that its a deletion or use something like that. I am not shure yet. I find it somethimes a bit hard to track unused files down and delete em (over several remotes).
So I like the direct mode, and some programs still have problems using that files, as example du dont give you real size except you use -D of files, and even nautilus supports basicly dropping files, you cant drop on other repository with it.
maybe I should also look how to easily remote git annex from some trees then I would be more willing to just play with that files around and go back to normal more painless, or I start with a smaller directory.
the real fun I guess happens if you automate things like cloning of some paths to another remote as soon as its available I guess. I also dont like the interfaces to annex to much, mv /mnt/share/file_x /path is just simpler than git annex move file_x --from=kodi --to=local-repos
but thats maybe just practise