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

[Dmitry Gutov <dgutov@yandex.ru>]

On 04.07.2012 19:10, Michael Albinus wrote:
>> Was the file absent in the branch test after checkout? If not, this
>> case is no different from the first.
>> Basically, we need a scenario in which `vc-next-action' will need to
>> call `vc-git-register' on a file that recently has been considered
>> up-to-date.
>
> If we assume, any command outside Emacs can happen which invalidates the
> cached status of a file, we must clear all caches and recompute all
> files state when vc-next-action is called. To the given cost.

I'd have no problem with this, actually - this function is called 
considerably less often than `find-file' or `save-buffer'.

> In Tramp, I have similar problems with stale caches. Finally, I've added
> timestamps to every cached value, and I use cheap tests to check whether
> the cache is out of date. No idea, whether we want go this direction in
> vc, too.

Can't commend on that.

> If we assume that there are no dangerous vc commands outside Emacs, we
> wouldn't have a problem.

In this case, the behavior of the first patch I posted here should be 
acceptable, right? It's simpler, has pretty much the same effect, and 
should be a tiny bit faster.

>> The logic is rather complicated there, so I might easily be missing
>> some examples.
>
> Yes. I don't know, whether we will be able to handle any surprise when
> using caches. There will always be a scenario which lets fail a given
> algorithm. I fear.

Sure, but I'm just asking for one scenario that works better with 
explicitly caching 'git-registered, instead of not calling it in 
`vc-git-state'.
If `vc-git-state' doesn't call `vc-git-registered' (just assumes it's 
t), then `vc-registered' is the latter's only client, and so its return 
value is implicitly cached in 'vc-backend property.