GNU bug report logs - #20637
incompatible, undocumented change to vc-working-revision

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Glenn Morris <rgm <at> gnu.org>, 20637 <at> debbugs.gnu.org
Subject: bug#20637: incompatible, undocumented change to vc-working-revision
Date: Fri, 1 Apr 2016 03:36:57 +0300

On 03/29/2016 09:13 PM, Michael Albinus wrote:

> Why is verifying such tests "the wrong thing"? It's a while ago that I
> wrote the tests, but IIRC I've added them exactly because I did expect
> that such tests should pass, and they didn't.

It's certainly not very meaningful to test this (it's better to compare 
to actual values; for all we know, the above method returns `fooled-ya' 
in both cases).

As far as it being wrong: it is, if you consider that some existing 
implementations don't expect to be called with FILE that's not 
registered. So different return values in these two cases are to be 
expected.

> I even fixed some trivial
> corner cases when writing the tests. as far as I understood the code.

Yes, you found some of those cases (but, like mentioned, not all), and 
that required double-checking that the file is indeed registered.

You can argue that the new semantics are more straightforward, and I 
don't disagree (the docstring of vc-state seems to agree already; 
vc-working-revision's docstring disagrees).

But the cost to that is extra process calls. I'm not sure if the changes 
in 7f9b037245ddb662ad98685e429a2498ae6b7c62 add any extra process calls, 
but they do add some interaction with the filesystem.

Fixing the newly introduced problem with vc-git-state would require an 
extra process call, more or less reverting the fix for bug#11757. I 
don't know how much of a problem that is (I haven't used Windows in a 
while, and my current laptop is faster that what I had back then 
anyway), but it would certainly be nice not to introduce a regression in 
features, or performance.

As far as vc-git-state, one way to do that is reimplementing some 
commands using 'git status --porcelain', introduced in Git 1.7.0. We 
should double-check if we're allowed to rely on this version being 
available (which Git does the the oldest relevant version of CentOS 
install now?), and it might be too late for Emacs 25.1 anyway.

Calling vc-responsible-backend is also inherently slower than 
vc-backend, though not perceptibly so on this localhost (4e-5s vs 
4e-6s). But it's likely more painful for remove hosts; how is it, in 
your experience?

Previous Next

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