Hi Ihor, Ihor Radchenko <yanta...@gmail.com> writes:
> Does it mean that your attachment folder is set in :DIR: property? No, my attachment folder is build using :ID: property. For example, in my heading: * Test :PROPERTIES: :ID: d0e690e2-2ecd-4224-891a-b91257db5389 :END: And if I evaluate `org-attach-dir' here, it returns the correct path: #+begin_src emacs-lisp (org-attach-dir) #+end_src #+RESULTS: : /home/juanmanuel/Documentos/docs-compartidos/org/data/d0/e690e2-2ecd-4224-891a-b91257db5389 But if I evaluate this, I get an 'incomplete' path: #+begin_src emacs-lisp (expand-file-name org-attach-id-dir) #+end_src #+RESULTS: : /home/juanmanuel/Documentos/docs-compartidos/org/data/ So if I replace `(expand-file-name org-attach-id-dir)' with `(org-attach-dir)' in `(org-attach-git-commit)' [line 7, the `dir' variable], it works fine when I run 'C-c C-a z'. Best regards Juan Manuel > > I suspect that it is a leftover from the major changes in org-attach > when :DIR: property was introduced. The org-attach-git presumes that all > the attachments in current file are stored in sub-directories located > inside org-attach-id-dir, which is no longer guaranteed. In fact, the > existing approach to treat all the attachments to all headings in > current file as files in a single git repo cannot be used. I can see two > possible fixes: > 1. Treat each attachment dir as individual git repo (breaking change for > those who are using :ID: property to build the attachment dirs) > 2. Treat attachment dirs defined by :DIR: property individually and > leave the :ID:-defined attachments as they were treated before > (inconsistent). > > I am in favour of the first approach since I do not like the idea of > keeping all the attachments in the whole file in a single git repo. > I think feedback from other is needed to decide what we need to do here. > > P.S. Marking this as a bug. > > Best, > Ihor >