From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jonathan H Newsgroups: gmane.emacs.bugs Subject: bug#21383: Static revisions in vc-working-revision Date: Wed, 2 Sep 2015 15:44:01 -0700 Message-ID: References: <55E41499.5030501@yandex.ru> <55E5094A.3010108@yandex.ru> <55E59487.1050804@yandex.ru> <55E5CA42.1080005@yandex.ru> <55E5DF1A.9010902@yandex.ru> <55E6D426.10105@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b2e10d1e36bb3051ecb687f X-Trace: ger.gmane.org 1441233925 23007 80.91.229.3 (2 Sep 2015 22:45:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 2 Sep 2015 22:45:25 +0000 (UTC) Cc: 21383-done@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Sep 03 00:45:14 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZXGmE-00066J-Sl for geb-bug-gnu-emacs@m.gmane.org; Thu, 03 Sep 2015 00:45:11 +0200 Original-Received: from localhost ([::1]:42099 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXGmE-0003Ze-PK for geb-bug-gnu-emacs@m.gmane.org; Wed, 02 Sep 2015 18:45:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39899) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXGmB-0003Ya-EZ for bug-gnu-emacs@gnu.org; Wed, 02 Sep 2015 18:45:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZXGm7-00077U-E1 for bug-gnu-emacs@gnu.org; Wed, 02 Sep 2015 18:45:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:54821) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXGm7-00076d-AQ for bug-gnu-emacs@gnu.org; Wed, 02 Sep 2015 18:45:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZXGm6-0001OY-KU for bug-gnu-emacs@gnu.org; Wed, 02 Sep 2015 18:45:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jonathan H Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Sep 2015 22:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21383 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21383-done@debbugs.gnu.org id=D21383.14412338745311 (code D ref 21383); Wed, 02 Sep 2015 22:45:02 +0000 Original-Received: (at 21383-done) by debbugs.gnu.org; 2 Sep 2015 22:44:34 +0000 Original-Received: from localhost ([127.0.0.1]:47031 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXGld-0001Nb-Lx for submit@debbugs.gnu.org; Wed, 02 Sep 2015 18:44:34 -0400 Original-Received: from mail-ig0-f175.google.com ([209.85.213.175]:37848) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXGlb-0001NR-9L for 21383-done@debbugs.gnu.org; Wed, 02 Sep 2015 18:44:32 -0400 Original-Received: by igbni9 with SMTP id ni9so26174448igb.0 for <21383-done@debbugs.gnu.org>; Wed, 02 Sep 2015 15:44:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xsEKr3zp4tpkEsC9uRBf4sFQn0iCWD4++sOL/5YEPAA=; b=cTImdw/cVgc+L2xdRfvKZCbcqkuRSZA+Y0zXvEvQnNzpiJZR++gsEWgqR2AqIXcweo mCGmhQ3M/k+tenodoRuLFZ8vVfwqZPk5CJHbNTAbrcCgEMKzbbHjqrPMiTKIPcSzcmi1 BKXPt+Lye5cI0lW+RuMRJ0Ri1hfPd8+uW1ADIiuoKpGP6a9B8Ly1TSmrNepnKvet6974 M8wW9KDgBr78EgCM+BzG/OptBZKxOKekFqmUXjjtJEoNSnyDRlGm6wYHmUR9MP6ZQqm0 laLLW6t/cTHmYX++beWoVE3sM5UPcPacPP2mIYKzsQDNwZTge3J4FbH8hc3undtq4Ue4 DI5Q== X-Received: by 10.50.98.7 with SMTP id ee7mr7426214igb.13.1441233870480; Wed, 02 Sep 2015 15:44:30 -0700 (PDT) Original-Received: by 10.79.110.197 with HTTP; Wed, 2 Sep 2015 15:44:01 -0700 (PDT) In-Reply-To: <55E6D426.10105@yandex.ru> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:106099 Archived-At: --047d7b2e10d1e36bb3051ecb687f Content-Type: text/plain; charset=UTF-8 Something seems a bit amiss with the current patch. I'm using (vc-working-revision buffer-file-name (vc-responsible-backend buffer-file-name)) to determine the current working revision. As far as I can tell, vc-working-revision will cache the current working revision in a file property, but it doesn't know when to invalidate the cache, so the results can be stale. In fact, in the specific case of git, you probably can't get any faster than a rev-parse anyway, so caching doesn't make much sense. I have a sneaking suspicion that git isn't the only backend where this can happen. Thanks, Jonathan On Wed, Sep 2, 2015 at 3:49 AM, Dmitry Gutov wrote: > On 09/02/2015 06:50 AM, Stefan Monnier wrote: > >> Maybe you see it better. I only imagined the problem limited to the >>> non-file-granularity backends. >>> >> >> You mean like most current backends? ;-) >> > > Yes. But as long as its only limited to the backends (and can be fixed > there), as opposed to being inherently present in vc.el, log-edit.el, etc, > it's less of a problem. > > And we can't simply remove the FILE argument in many backend commands: it's >>> often used for vc-file-get/setprop. >>> >> >> I know. >> >> In any case, it's not that bad: it works. But there's something fishy >> that will surely bite at some point. Maybe those FILE args should be >> redefined to be relative to default-directory (and can't use things like >> "../.."). >> > > vc-file-setprop won't work on a relative path. Or shouldn't, at least. > > And are you talking about FILE arg to vc-status, or e.g. vc-git-status? If > vc-status requires the path to be relative, that will complicate the > consumer interface (now I have to worry about producing the relative path). > If vc-status will be responsible for that before calling vc-git-status, it > won't work in file-granular backends. Anyway, why would we want that extra > call, even if it's cached? > > And vc-git-working-revision won't care if FILE is absolute or relative, > which is the crux of the problem. I'd rather backends like Git, if we're > going to fix this, used FILE's parent directory to change default-directory > temporarily before calling Git. > --047d7b2e10d1e36bb3051ecb687f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Something seems a bit amiss with the curren= t patch.

I'm using (vc-working-revision buffer-file-n= ame (vc-responsible-backend buffer-file-name)) to determine the current wor= king revision.

As far as I can tell, vc-working-rev= ision will cache the current working revision in a file property, but it do= esn't know when to invalidate the cache, so the results can be stale. I= n fact, in the specific case of git, you probably can't get any faster = than a rev-parse anyway, so caching doesn't make much sense.

I have a sneaking suspicion that git isn't the only backend whe= re this can happen.

Thanks,
Jonathan



On Wed, Sep 2, 2015 at 3:49 AM, Dmitry Gutov <dgutov@yande= x.ru> wrote:
On 09/02/2015 06:50 AM, Stefan Monnier wrote:
Maybe you see it better.=C2=A0 I only imagined the problem limited to the non-file-granularity backends.

You mean like most current backends? ;-)

 Yes. But as long as its only limited to the backends (and can be fixed ther= e), as opposed to being inherently present in vc.el, log-edit.el, etc, it&#= 39;s less of a problem.

And we can't simply remove the FILE argument in many backend commands: = it's
often used for vc-file-get/setprop.

I know.

In any case, it's not that bad: it works.=C2=A0 But there's somethi= ng fishy
that will surely bite at some point.=C2=A0 Maybe those FILE args should be<= br> redefined to be relative to default-directory (and can't use things lik= e
"../..").

 vc-file-setprop won't work on a relative path. Or shouldn't, at lea= st.

And are you talking about FILE arg to vc-status, or e.g. vc-git-status? If = vc-status requires the path to be relative, that will complicate the consum= er interface (now I have to worry about producing the relative path). If vc= -status will be responsible for that before calling vc-git-status, it won&#= 39;t work in file-granular backends. Anyway, why would we want that extra c= all, even if it's cached?

And vc-git-working-revision won't care if FILE is absolute or relative,= which is the crux of the problem. I'd rather backends like Git, if we&= #39;re going to fix this, used FILE's parent directory to change defaul= t-directory temporarily before calling Git.

--047d7b2e10d1e36bb3051ecb687f--