GNU bug report logs - #11757
24.1.50; vc-git calls `process-file' too many times

Previous Next

Full log

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 11757 <at> debbugs.gnu.org
Subject: Re: bug#11757: Acknowledgement (24.1.50; vc-git calls `process-file'
	too many times)
Date: Fri, 29 Jun 2012 21:03:20 +0400

On 29.06.2012 20:40, Michael Albinus wrote:
>>> 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.
>
> I see. Maybe we find a hook, where we could invalidate the vc cache when
> a file is written which does not exist on the disk?

(vc-before-save) might be the place to do that.

>> 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?
>
> When the file is removed from git outside Emacs. In this case,
> git-registered must be nil.

I meant, would that happen with your patch?
If vc-before-save would invalidate the cache, that should be ok.

>> 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.
>
> I try to remember. The Emacs maintainers prefer context diffs, that's
> why ediff-custom-diff-options is set to "-c" by default.

How important is that, I wonder? It's what CONTRIBUTE says, but I've 
seen many of the diffs posted in unified format, and no one ever asked 
me to convert a patch specifically into context format.

Previous Next

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