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

Previous Next

Full log

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

From: <miha <at> kamnitnik.top>
To: Michael Albinus <michael.albinus <at> gmx.de>, 55578 <at> debbugs.gnu.org
Subject: Re: bug#55578: 29.0.50; auto-revert-use-notify vs 'git checkout --
 <file>'
Date: Tue, 24 May 2022 17:58:36 +0200

[Message part 1 (text/plain, inline)]

Michael Albinus <michael.albinus <at> gmx.de> writes:

> 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.

I imagine that after receiving a 'delete' event, auto-revert-mode could
set up a file-notify watch handler on the directory containing the (now
deleted) file. This handler would respond to a 'create' event
corresponding to the filename by reverting the buffer, removing the
directory file-notify watch and (re-)adding an ordinary file-notify
handler on the file.

Are there any obvious flaws with this approach that I'm missing?

> Best regards, Michael.

Best regards.

[signature.asc (application/pgp-signature, inline)]

Previous Next

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