Breaks when using TRAMP
PythonNut opened this issue · comments
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.
@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?
@tsdh I think it does work doesn't it? The fact that it loops indicates that the file notification system is working, right?
@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...
@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.
@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.
The .git directory is not watched at all with the current code so that shouldn't be the issue.
@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.
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
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22454 is fixed. Is this still an issue?
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.
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?
@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.