Hi Erik, Erik Hetzner <e...@e6h.org> writes:
> If a user prefers to use git annex assistant or preferred content that > shouldn’t > interfere with this. But to my mind, opening an attachment is a pretty clear > indication of the user’s desire to fetch the file from git annex, so it would > be > nice to do it. Yes, there’s no harm. Thanks for the pointer to the bug "git annex open". Combining "git annex find" and "git annex get" seems like a fine solution. >> […] >> >> IMO we should get rid of org-attach-git-annex-cutoff and point to >> preferred content: >> >> http://git-annex.branchable.com/preferred_content/ >> >> E.g. I might have a small mp3 file. There's no point in storing it with >> git rather than git annex. >> >> When preferred content is set up, I think git annex add will do the >> right thing. > > I’m not certain how preferred content works, but it doesn’t seem to apply to > which content is added to git annex (as opposed to added to the git repo > itself), which is what org-attach-git-annex-cutoff does. Sorry. What I was thinking of is annex.largefiles, which /uses/ the preferred contents syntax. E.g. in my config.annex I use the following setting: [annex] ... largefiles = (largerthan=200kb or include=*.otf or include=*.ttf) and not (include=*.json or include=*.el or include=*.org) Files that are not largefiles are checked in as normal git files. Example: $ git annex find .fonts/FiraMono-BoldItalic.ttf .fonts/FiraMono-BoldItalic.ttf # → checked in in annex. $ git annex find .emacs.d/init.el $ git log -n1 --oneline -- .emacs.d/init.el 9a8fd3a git-annex in W530: conf.annex # → checked in in vanilla git. Rasmus -- This message is brought to you by the department of redundant departments
