emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* org-attach-git don't automatically commit changes
@ 2021-01-29 16:03 Juan Manuel Macías
  2021-01-30  5:10 ` Ihor Radchenko
  0 siblings, 1 reply; 11+ messages in thread
From: Juan Manuel Macías @ 2021-01-29 16:03 UTC (permalink / raw)
  To: orgmode

Hi,

I don't know if this is a bug or if I am doing something wrong...

According to the manual:

#+begin_quote
If the directory attached to an outline node is a Git
repository, Org can be configured to automatically commit changes to
that repository when it sees them.

To make Org mode take care of versioning of attachments for you, add the
following to your Emacs config:

(require 'org-attach-git)
#+end_quote

I don't see that org-attach "automatically commit changes when it sees
them". Only when I run in the attached directory `M-:
(org-attach-git-commit) RET' it works fine.

`org-attach-after-change-hook' is set to `(org-attach-git-commit)'.

Regards,

Juan Manuel 



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: org-attach-git don't automatically commit changes
  2021-01-29 16:03 org-attach-git don't automatically commit changes Juan Manuel Macías
@ 2021-01-30  5:10 ` Ihor Radchenko
  2021-01-30 13:38   ` Juan Manuel Macías
  0 siblings, 1 reply; 11+ messages in thread
From: Ihor Radchenko @ 2021-01-30  5:10 UTC (permalink / raw)
  To: Juan Manuel Macías, orgmode

Juan Manuel Macías <maciaschain@posteo.net> writes:

> I don't see that org-attach "automatically commit changes when it sees
> them". Only when I run in the attached directory `M-:
> (org-attach-git-commit) RET' it works fine.

Note that org "sees" changes in the attachment dir only when you use
M-x org-attach command to manage the attachments. Directly changing the
attachment directory will not be noticed. You can force org-mode to
check for changes in attachment dir by running "C-c C-a z".

I guess using something like inotify might be a good new feature to
make org detect changes automatically.

Best,
Ihor



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: org-attach-git don't automatically commit changes
  2021-01-30  5:10 ` Ihor Radchenko
@ 2021-01-30 13:38   ` Juan Manuel Macías
  2021-01-31  3:33     ` Ihor Radchenko
  0 siblings, 1 reply; 11+ messages in thread
From: Juan Manuel Macías @ 2021-01-30 13:38 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Hi Ihor,

Ihor Radchenko <yantar92@gmail.com> writes:

> Note that org "sees" changes in the attachment dir only when you use
> M-x org-attach command to manage the attachments. Directly changing the
> attachment directory will not be noticed. You can force org-mode to
> check for changes in attachment dir by running "C-c C-a z".

Thanks for the explanation. It seems that I had misinterpreted
what the manual said :-)

Anyway, in my case, it still doesn't work (?). I think it's for a path
problem. In `org-attach-git-commit' there is this variable:

#+begin_src emacs-lisp
;; ...
  (let* ((dir (expand-file-name org-attach-id-dir))
;; ...
#+end_src

The default value of `org-attach-id-dir' is "data/", and if I evaluate
`(expand-file-name org-attach-id-dir)' on my current node, it returns a
wrong path to the attached folder. `org-attach-sync' only works for me
if I set in `org-attach-git-commit' the variable like this:

#+begin_src emacs-lisp
;; ...
  (let* ((dir (org-attach-dir)) ;; <====
;; ...
#+end_src

In that case, it does recognize the path correctly. Again, I don't
know if I'm missing something...

Best regards,

Juan Manuel 


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: org-attach-git don't automatically commit changes
  2021-01-30 13:38   ` Juan Manuel Macías
@ 2021-01-31  3:33     ` Ihor Radchenko
  2021-01-31 10:29       ` Juan Manuel Macías
  0 siblings, 1 reply; 11+ messages in thread
From: Ihor Radchenko @ 2021-01-31  3:33 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

Juan Manuel Macías <maciaschain@posteo.net> writes:

> The default value of `org-attach-id-dir' is "data/", and if I evaluate
> `(expand-file-name org-attach-id-dir)' on my current node, it returns a
> wrong path to the attached folder. `org-attach-sync' only works for me
> if I set in `org-attach-git-commit' the variable like this:

Does it mean that your attachment folder is set in :DIR: property?

> #+begin_src emacs-lisp
> ;; ...
>   (let* ((dir (expand-file-name org-attach-id-dir))
> ;; ...
> #+end_src

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




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: org-attach-git don't automatically commit changes
  2021-01-31  3:33     ` Ihor Radchenko
@ 2021-01-31 10:29       ` Juan Manuel Macías
  2021-01-31 10:52         ` Ihor Radchenko
  0 siblings, 1 reply; 11+ messages in thread
From: Juan Manuel Macías @ 2021-01-31 10:29 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Hi Ihor,

Ihor Radchenko <yantar92@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
>



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: org-attach-git don't automatically commit changes
  2021-01-31 10:29       ` Juan Manuel Macías
@ 2021-01-31 10:52         ` Ihor Radchenko
  2021-01-31 11:41           ` Juan Manuel Macías
  2021-01-31 13:16           ` Juan Manuel Macías
  0 siblings, 2 replies; 11+ messages in thread
From: Ihor Radchenko @ 2021-01-31 10:52 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

Juan Manuel Macías <maciaschain@posteo.net> writes:

> But if I evaluate this, I get an 'incomplete' path:

I think you misunderstood how org-attach-git works.

org-attach-git is:

;; An extension to org-attach.  If `org-attach-id-dir' is initialized
;; as a Git repository, then org-attach-git will automatically commit
;; changes when it sees them.  Requires git-annex.

So, it is not designed to work when your actual attachment directory is
a git repo, but rather when org-attach-id-dir is a git repo (initialised
manually).

The other thing is that `org-attach-id-dir' makes much less sense from
the time :DIR: property was introduced. So, I believe that
org-attach-git should be updated. Probably, handling attachment dirs as
individual git repos can be one of the ways to upgrade the current
version. I guess, patches welcome.

Best,
Ihor




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: org-attach-git don't automatically commit changes
  2021-01-31 10:52         ` Ihor Radchenko
@ 2021-01-31 11:41           ` Juan Manuel Macías
  2021-01-31 13:16           ` Juan Manuel Macías
  1 sibling, 0 replies; 11+ messages in thread
From: Juan Manuel Macías @ 2021-01-31 11:41 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko <yantar92@gmail.com> writes:

> I think you misunderstood how org-attach-git works.
>
> org-attach-git is:
>
> ;; An extension to org-attach.  If `org-attach-id-dir' is initialized
> ;; as a Git repository, then org-attach-git will automatically commit
> ;; changes when it sees them.  Requires git-annex.
>
> So, it is not designed to work when your actual attachment directory is
> a git repo, but rather when org-attach-id-dir is a git repo (initialised
> manually).

Thanks for the explanation: it is clear that I had misinterpreted
`org-attach-id-dir'. Now it makes sense that it didn't work for me.
Anyway, I think the manual at that point is somewhat ambiguous and it
should be more precise, IMHO.

> So, I believe that org-attach-git should be updated. Probably,
> handling attachment dirs as individual git repos can be one of the
> ways to upgrade the current version.

I agree, I think this possibility makes a lot more sense.

Best regards,

Juan Manuel 


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: org-attach-git don't automatically commit changes
  2021-01-31 10:52         ` Ihor Radchenko
  2021-01-31 11:41           ` Juan Manuel Macías
@ 2021-01-31 13:16           ` Juan Manuel Macías
  2021-01-31 13:40             ` Ihor Radchenko
  1 sibling, 1 reply; 11+ messages in thread
From: Juan Manuel Macías @ 2021-01-31 13:16 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko <yantar92@gmail.com> writes:

> The other thing is that `org-attach-id-dir' makes much less sense from
> the time :DIR: property was introduced. So, I believe that
> org-attach-git should be updated. Probably, handling attachment dirs as
> individual git repos can be one of the ways to upgrade the current
> version. I guess, patches welcome.

Do you think a possible patch could simply consist of replacing (as I
have done) `(expand-file-name org-attach-id-dir)' by `(org-attach-dir)'
in `org-attach-git-commit'? This would allow you to handle attachment
dirs as individual git repos, regardless of :ID: or :DIR: properties,
since "[(org-attach-dir)] Return the directory associated with the
current outline node. First check for DIR property, then ID property
[...]".

Best regards,

Juan Manuel 


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: org-attach-git don't automatically commit changes
  2021-01-31 13:16           ` Juan Manuel Macías
@ 2021-01-31 13:40             ` Ihor Radchenko
  2021-01-31 14:36               ` Juan Manuel Macías
  0 siblings, 1 reply; 11+ messages in thread
From: Ihor Radchenko @ 2021-01-31 13:40 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

Juan Manuel Macías <maciaschain@posteo.net> writes:

> Do you think a possible patch could simply consist of replacing (as I
> have done) `(expand-file-name org-attach-id-dir)' by `(org-attach-dir)'
> in `org-attach-git-commit'? This would allow you to handle attachment
> dirs as individual git repos, regardless of :ID: or :DIR: properties,
> since "[(org-attach-dir)] Return the directory associated with the
> current outline node. First check for DIR property, then ID property
> [...]".

All the instances of (expand-file-name org-attach-id-dir) should be
replaced. There are 3. That's not a big deal.

What is more tricky is making sure that workflow for people using the
old behaviour is not broken. Just changing to (org-attach-dir) will
break existing git repos in org-attach-id-dir. This should also not be
too hard (say, we can introduce a custom variable defaulting to old
behaviour), but exact details may need to be discussed.

In any case, if you provide a patch, it will encourage the org
maintainers to join this discussion and proceed with changes.

Best,
Ihor


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: org-attach-git don't automatically commit changes
  2021-01-31 13:40             ` Ihor Radchenko
@ 2021-01-31 14:36               ` Juan Manuel Macías
  2024-01-10 16:05                 ` Ihor Radchenko
  0 siblings, 1 reply; 11+ messages in thread
From: Juan Manuel Macías @ 2021-01-31 14:36 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko <yantar92@gmail.com> writes:

> What is more tricky is making sure that workflow for people using the
> old behaviour is not broken. Just changing to (org-attach-dir) will
> break existing git repos in org-attach-id-dir. This should also not be
> too hard (say, we can introduce a custom variable defaulting to old
> behaviour), but exact details may need to be discussed.

I agree: I think a custom variable with the current behavior by default
would be fine.

> In any case, if you provide a patch, it will encourage the org
> maintainers to join this discussion and proceed with changes.

OK, this week I will try to propose a patch here, and bring it up for
(possible) discussion. Thanks for the suggestions.

Best regards,

Juan Manuel 


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: org-attach-git don't automatically commit changes
  2021-01-31 14:36               ` Juan Manuel Macías
@ 2024-01-10 16:05                 ` Ihor Radchenko
  0 siblings, 0 replies; 11+ messages in thread
From: Ihor Radchenko @ 2024-01-10 16:05 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Ihor Radchenko, orgmode

Juan Manuel Macías <maciaschain@posteo.net> writes:

>> In any case, if you provide a patch, it will encourage the org
>> maintainers to join this discussion and proceed with changes.
>
> OK, this week I will try to propose a patch here, and bring it up for
> (possible) discussion. Thanks for the suggestions.

For the record, this appears to be fixed in df9b509a6.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2024-01-10 16:03 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-01-29 16:03 org-attach-git don't automatically commit changes Juan Manuel Macías
2021-01-30  5:10 ` Ihor Radchenko
2021-01-30 13:38   ` Juan Manuel Macías
2021-01-31  3:33     ` Ihor Radchenko
2021-01-31 10:29       ` Juan Manuel Macías
2021-01-31 10:52         ` Ihor Radchenko
2021-01-31 11:41           ` Juan Manuel Macías
2021-01-31 13:16           ` Juan Manuel Macías
2021-01-31 13:40             ` Ihor Radchenko
2021-01-31 14:36               ` Juan Manuel Macías
2024-01-10 16:05                 ` Ihor Radchenko

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).