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?
next prev parent 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).