bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#55578: 29.0.50; auto-revert-use-notify vs 'git checkout -- <file>'


From: Michael Albinus
Subject: bug#55578: 29.0.50; auto-revert-use-notify vs 'git checkout -- <file>'
Date: Tue, 24 May 2022 14:02:35 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

miha--- via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@gnu.org> writes:

Hi,

> Visit a file in a clean git repository, modify it and save its buffer.
> Turn on auto-revert-mode in its buffer.
>
> Run 'git checkout -- <filename>' and notice that auto-revert-mode
> doesn't revert the buffer immediately using 'notify', it only reverts it
> according to auto-revert-interval.
>
> This is in contrast to modifying the file with a command like
> 'echo test >> <filename>', after which auto-revert-mode reverts the
> buffer instantly using 'notify'.
>
> This seems to be because prior to writing the file, 'git checkout'
> unlinks it first. It would be nice if auto-revert-mode worked with
> notify in such cases as well.

Indeed, git deletes and (re-)creates the file. See the following file
notify events, when monitoring the git repository (/tmp/xxx is the repo,
/tmp/xxx/foo the file). This happens, after calling "git checkout -- foo":

--8<---------------cut here---------------start------------->8---
file-notify-handle-event (file-notify ((1 . 0) (delete) "foo" 0) 
file-notify--callback-inotify)
file-notify-handle-event (file-notify ((1 . 0) (create) "foo" 0) 
file-notify--callback-inotify)
file-notify-handle-event (file-notify ((1 . 0) (modify) "foo" 0) 
file-notify--callback-inotify)
--8<---------------cut here---------------end--------------->8---

The corresponding events for the file /tmp/xxx/foo are

--8<---------------cut here---------------start------------->8---
file-notify-handle-event (file-notify ((1 . 1) (delete) "foo" 0) 
file-notify--callback-inotify)
file-notify-callback (1 . 1) deleted "/tmp/xxx/foo" nil #s(file-notify--watch 
"/tmp/xxx" "foo" auto-revert-notify-handler) "/tmp/xxx/foo" "/tmp/xxx"
auto-revert-notify-handler ((1 . 1) deleted "/tmp/xxx/foo")
file-notify-handle-event (file-notify ((1 . 1) stopped "/tmp/xxx/foo") 
auto-revert-notify-handler)
auto-revert-notify-handler ((1 . 1) stopped "/tmp/xxx/foo")
--8<---------------cut here---------------end--------------->8---

As you can see, file notifications are stopped after receiving the
'delete' event. This is a feature of our file notifications implementation.

Running "echo test >> foo" instead shows the events

--8<---------------cut here---------------start------------->8---
file-notify-handle-event (file-notify ((1 . 0) (modify) "foo" 0) 
file-notify--callback-inotify)
file-notify-callback (1 . 0) changed "/tmp/xxx/foo" nil #s(file-notify--watch 
"/tmp/xxx" nil auto-revert-notify-handler) "/tmp/xxx" "/tmp/xxx"
auto-revert-notify-handler ((1 . 0) changed "/tmp/xxx/foo")
--8<---------------cut here---------------end--------------->8---

This works as expected. So I fear there's nothing we can do.

Best regards, Michael.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]