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

[Michael Albinus <michael.albinus@gmx.de>]

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.