From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rasmus Subject: Re: [PATCH] org-attach.el: Fetch attachments from git annex Date: Wed, 06 Jan 2016 10:37:26 +0100 Message-ID: <87a8ojkq09.fsf@gmx.us> References: <568b532e.d111620a.b25a8.ffffbb7c@mx.google.com> <568b5e82.0406430a.a1c6a.0ce9@mx.google.com> <568c6d77.2983420a.8a565.3478@mx.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:36174) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aGkXE-0007g6-Ap for emacs-orgmode@gnu.org; Wed, 06 Jan 2016 04:37:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aGkXA-0002yq-83 for emacs-orgmode@gnu.org; Wed, 06 Jan 2016 04:37:40 -0500 Received: from plane.gmane.org ([80.91.229.3]:33147) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aGkXA-0002yS-1n for emacs-orgmode@gnu.org; Wed, 06 Jan 2016 04:37:36 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1aGkX8-0003kM-P2 for emacs-orgmode@gnu.org; Wed, 06 Jan 2016 10:37:35 +0100 Received: from 62.80.108.10 ([62.80.108.10]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 Jan 2016 10:37:34 +0100 Received: from rasmus by 62.80.108.10 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 Jan 2016 10:37:34 +0100 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Hi Erik, Erik Hetzner 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