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

Previous Next

Full log

Message #8 received at 55578 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: miha--- via "Bug reports for GNU Emacs, the Swiss army knife of text
 editors" <bug-gnu-emacs <at> gnu.org>
Cc: 55578 <at> debbugs.gnu.org, miha <at> kamnitnik.top
Subject: Re: bug#55578: 29.0.50; auto-revert-use-notify vs 'git checkout --
 <file>'
Date: Tue, 24 May 2022 14:02:35 +0200

miha--- via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.