unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Dmitry Gutov <dgutov@yandex.ru>
To: Michael Albinus <michael.albinus@gmx.de>
Cc: 11757@debbugs.gnu.org
Subject: bug#11757: Acknowledgement (24.1.50; vc-git calls `process-file' too many times)
Date: Fri, 29 Jun 2012 20:06:56 +0400	[thread overview]
Message-ID: <4FEDD2A0.3010300@yandex.ru> (raw)
In-Reply-To: <87d34igrie.fsf@gmx.de>

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
>> tradeoff.
>
> 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	other threads:[~2012-06-29 16:06 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-21  2:12 bug#11757: 24.1.50; vc-git calls `process-file' too many times Dmitry Gutov
     [not found] ` <handler.11757.B.13402450035158.ack@debbugs.gnu.org>
2012-06-26 10:54   ` bug#11757: Acknowledgement (24.1.50; vc-git calls `process-file' too many times) Dmitry Gutov
2012-06-26 12:14     ` Michael Albinus
2012-06-28  0:51       ` Dmitry Gutov
2012-06-29 13:46         ` Michael Albinus
2012-06-29 16:06           ` Dmitry Gutov [this message]
2012-06-29 16:40             ` Michael Albinus
2012-06-29 17:03               ` Dmitry Gutov
2012-06-29 17:38                 ` Michael Albinus
2012-06-30  9:03                 ` Michael Albinus
2012-06-30 12:56                   ` Dmitry Gutov
2012-06-30 13:19                     ` Michael Albinus
2012-06-30 17:42                       ` Dmitry Gutov
2012-06-30 18:46                         ` Michael Albinus
2012-06-30 19:14                           ` Dmitry Gutov
2012-07-01  9:58                             ` Michael Albinus
2012-07-01 14:58                               ` Dmitry Gutov
     [not found]                               ` <4FF062D7.7050402@yandex.ru>
     [not found]                                 ` <878vf2sf7q.fsf@gmx.de>
2012-07-02 12:42                                   ` Dmitry Gutov
2012-07-02 12:44                                   ` Dmitry Gutov
2012-07-04 15:10                                     ` Michael Albinus
2012-07-04 16:42                                       ` Dmitry Gutov
2012-07-06 13:44                                         ` Michael Albinus
2012-07-06 15:55                                           ` Dmitry Gutov
     [not found]                                             ` <5000D21F.6080900@yandex.ru>
     [not found]                                               ` <87k3y36gbe.fsf@gmx.de>
     [not found]                                                 ` <50046AD3.1080605@yandex.ru>
     [not found]                                                   ` <87y5min9ad.fsf@gmx.de>
     [not found]                                                     ` <50063692.7080707@yandex.ru>
2012-07-18 14:38                                                       ` Michael Albinus
2012-07-18 17:01                                                         ` Dmitry Gutov
2012-06-30 23:01             ` Stefan Monnier
2012-06-30 23:38               ` Dmitry Gutov
2012-07-18 14:11 ` bug#11757: Fwd: " Michael Albinus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FEDD2A0.3010300@yandex.ru \
    --to=dgutov@yandex.ru \
    --cc=11757@debbugs.gnu.org \
    --cc=michael.albinus@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).