Breaks when using TRAMP

[PythonNut]

If magit-filenotify is enabled and magit-status is called on a TRAMP directory, the buffer will be caught in an infinite loop because of the extra delay of TRAMP causing magit-filenotify to trigger its own refresh conditions.

[tsdh]

@PythonNut Can file notifications work at all for remote directories? I guess not, so a simple yet proper fix was to not activate magit-filenotify-mode if (file-remote-p default-directory) returns t, no?

[PythonNut]

@tsdh I think it does work doesn't it? The fact that it loops indicates that the file notification system is working, right?

[tsdh]

@PythonNut Good point. :-)

Hm, I just tried to reproduce the issue by finding a git working copy directory on a remote server and doing M-x magit-status but I get the error: tramp-file-name-handler: No file notification program found on /ssh:horn@jiffybox:.

And now I tried on a different remote but then M-x magit-status asks me for which project to open the status buffer meaning that it didn't even recognize that the remote file or directory is tracked by git...

[tsdh]

@PythonNut Well, actually I don't understand your description completely. magit-filenotify's refresh conditions are "something in a repo dir changed on disk". How does firing up or refreshing a magit status buffer change something on disk?

But anyway, it is possible that my PR #12 already solves this issue by accident. Essentially, it delays magit status buffer refreshes as long as new file notifications keep coming in in a short period of time. So please test if you find some time.

[PythonNut]

@tsdh git uses a lockfile (/.git/index.lock) to ensure that operations don't collide, so checking the status will create and destroy /.git/index.lock, which triggers the filenotify listener.

I'll look into your PR when I get a few spare minutes.

[tsdh]

The .git directory is not watched at all with the current code so that shouldn't be the issue.

[juergenhoetzel]

@PythonNut Good point. :-)

Hm, I just tried to reproduce the issue by finding a git working copy directory on a remote server and doing M-x magit-status but I get the error: tramp-file-name-handler: No file notification program found on /ssh:horn@jiffybox:.

Actually magit-filenotify works fine on remote repos, if gvfs-monitor-dir is installed.

It just seems to hang if it has to handle too many remote directories (A SSH+gvfs-monitor-dir process is spawned for every subdir). Actually its not usable on big repos.

I use GNU Emacs 24.5 and the tramp master branch.

[npostavs]

Not sure how relevant this is since I haven't been following this thread, but

The .git directory is not watched at all with the current code so that shouldn't be the issue.

The file watching mechanism may cast a wider net than you expect, cf magit/magit#2454 (comment) and http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22454

[ruediger]

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22454 is fixed. Is this still an issue?

[npostavs]

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22454 is fixed.

It's not "fixed" exactly, I closed it because there was no bug in Emacs: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22454#13

So depending on the filesystem, it's possible that changes inside .git/ would trigger notifications events about the .git/ directory changing, even if Emacs is not listening for changes inside .git/. I'm not sure how relevant that is to this bug.

[alphapapa]

I just got the No file notification program found error when I tried to use magit-status on a remote machine through TRAMP. Is there any way to use Magit without the notification monitoring?

[ruediger]

@alphapapa magit-filenotify is just an optional mode. You can run Magit without it. M-x magit-filenotify-mode RET will disable it. Remove it from magit-status-hook-mode to no longer automatically start it.