[Sorry if this is a duplicate; my mail server got (incorrectly) placed
in a spam blocking list and some fraction of my mail never reached its
intended recipient]
[Because I seem to be the one that can see these messages; I'm  
forwarding them to the list]

Begin forwarded message:

> From: Marcin Bachry <[email protected]>
> Date: April 16, 2009 6:10:22 AM EDT
> To: David Abrahams <[email protected]>
> Subject: Re: tramp (2.1.16-pre); Needless remote access?
>
> 2009/4/16 David Abrahams <[email protected]>:
>> I'm not sure how this could have happened, but I just found TRAMP
>> initiating remote acesses when I was staging/un-staging files in  
>> magit
>> on a *local* git repository.  I did (setq default-directory "~") in  
>> the
>> magit buffer to try to stop it, to no avail.
>
> I can reproduce it by typing "g" (magit-refresh) in magit status
> buffer. I think the function "magit-revert-buffers" (run from
> "magit-refresh-wrapper") is responsible for the bug: it scans all
> buffers (including tramp ones) and does file operation on them
> ("verify-visited-file-modtime" function). This wakes up tramp
> connections and is generally slow.
>
> One obvious workaround is to ignore remote buffers using
> "buffer-remote-p". But I bet there's a smarter solution...
>
> m.
>
Begin forwarded message:

> From: Michael Albinus <[email protected]>
> Date: April 16, 2009 9:24:04 AM EDT
> To: David Abrahams <[email protected]>
> Cc: [email protected]
> Subject: Re: tramp (2.1.16-pre); Needless remote access?
>
> David Abrahams <[email protected]> writes:
>
>>>> I also have been unable to force the problem to be reproduced so  
>>>> far.
>>>
>>> No idea about. For further analysis from Tramp pov, I would need a
>>> scenario to reproduce it ...
>>>
>> I think this might explain it:
>
> Thanks! So I happily ignore it, because it must be fixed in magit.
>
> Maybe they can implement something like `recentf-keep', which calls
> `recentf-keep-default-predicate' with special handling of remote  
> files.
>
> Best regards, Michael.
>

--
David Abrahams
BoostPro Computing
http://boostpro.com




Reply via email to