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: 20637@debbugs.gnu.org
Subject: bug#20637: incompatible, undocumented change to vc-working-revision
Date: Fri, 1 Apr 2016 03:36:57 +0300	[thread overview]
Message-ID: <e979cc42-8e2a-01a4-66c2-5a429e54ff2d@yandex.ru> (raw)
In-Reply-To: <87mvphnoei.fsf@gmx.de>

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?





  reply	other threads:[~2016-04-01  0:36 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-23 23:49 bug#20637: incompatible, undocumented change to vc-working-revision Glenn Morris
2016-03-28 23:28 ` Dmitry Gutov
2016-03-29 18:13   ` Michael Albinus
2016-04-01  0:36     ` Dmitry Gutov [this message]
2016-04-09 19:34       ` Michael Albinus
2016-04-09 20:42         ` Dmitry Gutov
2016-04-10  8:00           ` Michael Albinus
2016-04-10 16:00             ` Dmitry Gutov
2016-04-10 18:09               ` Michael Albinus
2016-04-10 18:58                 ` Dmitry Gutov
2016-04-11  6:55                   ` Michael Albinus
2016-04-13 20:55                     ` Dmitry Gutov
2016-04-14  7:10                       ` Michael Albinus
2016-04-14 13:53                         ` Dmitry Gutov
2016-04-14 15:26                           ` Michael Albinus
2016-04-15  0:33                             ` Dmitry Gutov
2016-04-15 13:13                               ` Michael Albinus
2016-04-14 15:23                         ` Eli Zaretskii
2016-04-13 15:14   ` Michael Albinus
2016-04-13 20:49     ` Dmitry Gutov
2016-04-14  7:21       ` Michael Albinus
2016-04-14 14:20         ` Dmitry Gutov
2016-04-14 18:31           ` Michael Albinus
2016-04-15  0:20             ` Dmitry Gutov
2016-04-15 13:11               ` Michael Albinus
2016-04-17  0:44                 ` Dmitry Gutov
2016-04-18 12:27                   ` Michael Albinus
2016-04-18 12:33                     ` Dmitry Gutov
2016-04-18 12:46                       ` Michael Albinus
2016-04-18  1:40                 ` Dmitry Gutov
2016-04-15  1:01             ` Dmitry Gutov
2016-04-15  1:04               ` Dmitry Gutov
2016-04-15 13:23               ` Michael Albinus
2016-04-17  0:27                 ` Dmitry Gutov
2016-04-18  1:33             ` Dmitry Gutov
2016-04-18 12:28               ` Michael Albinus
2016-04-18 12:37                 ` Dmitry Gutov
2016-04-18 12:53                   ` Michael Albinus
2016-04-18 12:58                     ` Dmitry Gutov
2016-04-18 13:06                       ` Michael Albinus
2016-04-18 16:34                     ` John Wiegley

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=e979cc42-8e2a-01a4-66c2-5a429e54ff2d@yandex.ru \
    --to=dgutov@yandex.ru \
    --cc=20637@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).