[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#11757: Acknowledgement (24.1.50; vc-git calls `process-file' too man

From: Dmitry Gutov
Subject: bug#11757: Acknowledgement (24.1.50; vc-git calls `process-file' too many times)
Date: Fri, 29 Jun 2012 20:06:56 +0400
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1

On 29.06.2012 17:46, Michael Albinus wrote:
This little patch shaves 2 `process-file' invocations from both
vc-find-file-hook' and `vc-after-save'.

It's not fully backward-compatible (it breaks when a previously
registered file became unregistered), but I think it's a good

I don't know whether we shall break the functionality. Instead of, I've
appended a small patch, which uses the cache for vc-git-registered and
vc-git-root (additionally to your patch, which uses the cache of
vc-working-revision). This reduces already the number of process-file
invocations from 6 to 4, when openening a new file. And there's room for
other caches.

Looks like the win is the same here.

I'm not sure about caching vc-git-root, since at least in local scenario it's a fast operation. Is it that slow with Tramp?
Other backends don't cache it either.

VC doesn't handle all cases of "outside interference" anyway: for
example, the cached return value of `vc-working-revision' is
invalidated only after the file is checked in, moved, or deleted, not
after each save, and switching to another branch in Git is a much more
common occurrence.

A stale cache is bad, of course. We must carefully check, where a cached
value has to be invalidated. But why should vc-working-revision being
invalidated after saving? It is still the same, I believe. Switching to
another branch shall be observed by Emacs, 'cause there is another
version of the file on the disk, and Emacs warns you before editing.

This won't happen in following cases:
1) We switch to revision when the opened file is the same.
2) It doesn't exist there.
3) We just delete it from disk from outside of Emacs.
So the file isn't changed, and you see no warning or update, even after you write it to disk from Emacs again.

And the latter two cases (the last one - with a small modification) are the only situations I can think of when an open buffer in which (vc-git-registered) returned t some time ago (so it has vc-backend property set to Git) now should return nil.
But the properties won't be reset, so the cached value will be outdated.

Can you describe a scenario in which 'git-registered cached value will be invalidated, and the function will then return nil?

P.S. I can't find a way to apply context diff with my current setup, so if it's not too hard, please send a unified one next time.

-- Dmitry

reply via email to

[Prev in Thread] Current Thread [Next in Thread]