From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#20637: incompatible, undocumented change to vc-working-revision Date: Wed, 13 Apr 2016 23:49:12 +0300 Message-ID: References: <6ok2vyzwf9.fsf@fencepost.gnu.org> <08f70cda-44be-0657-e50a-2b2c80d2c21c@yandex.ru> <87oa9dzgl0.fsf@gmx.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1460580626 18061 80.91.229.3 (13 Apr 2016 20:50:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 13 Apr 2016 20:50:26 +0000 (UTC) Cc: 20637@debbugs.gnu.org To: Michael Albinus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Apr 13 22:50:16 2016 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 1aqRjr-00035I-OO for geb-bug-gnu-emacs@m.gmane.org; Wed, 13 Apr 2016 22:50:16 +0200 Original-Received: from localhost ([::1]:51906 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqRjr-00080T-4c for geb-bug-gnu-emacs@m.gmane.org; Wed, 13 Apr 2016 16:50:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36643) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqRji-0007nX-4g for bug-gnu-emacs@gnu.org; Wed, 13 Apr 2016 16:50:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aqRje-0003sw-TT for bug-gnu-emacs@gnu.org; Wed, 13 Apr 2016 16:50:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:49934) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqRje-0003sq-QG for bug-gnu-emacs@gnu.org; Wed, 13 Apr 2016 16:50:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1aqRje-0005GQ-6q for bug-gnu-emacs@gnu.org; Wed, 13 Apr 2016 16:50:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 13 Apr 2016 20:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20637 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 20637-submit@debbugs.gnu.org id=B20637.146058056320179 (code B ref 20637); Wed, 13 Apr 2016 20:50:02 +0000 Original-Received: (at 20637) by debbugs.gnu.org; 13 Apr 2016 20:49:23 +0000 Original-Received: from localhost ([127.0.0.1]:34038 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aqRj0-0005FP-S2 for submit@debbugs.gnu.org; Wed, 13 Apr 2016 16:49:23 -0400 Original-Received: from mail-wm0-f53.google.com ([74.125.82.53]:37537) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aqRiz-0005FC-AJ for 20637@debbugs.gnu.org; Wed, 13 Apr 2016 16:49:21 -0400 Original-Received: by mail-wm0-f53.google.com with SMTP id n3so97854313wmn.0 for <20637@debbugs.gnu.org>; Wed, 13 Apr 2016 13:49:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=NR1bFXgoDOyerqggjqur4dsgq3hiUlZfeIgwxnPcI1I=; b=brhwAP6+eYztCdJaC8OTrXeqPK7TOUP5hO5L9dRcbOp2I4b/u0FEv2PZ5W8zJoe70v 2xFuCiozNvtMfPBPoNNieV7wFh/XHhqyMYHPSfXNEAhoLM+/r4GgOI0qBfRPoCAUKEgl JceWuSw+T9eAzBPvUVHIO/qse5jxOhMz86GBHwOhaaEIKCS1fTfBPcstXe7eJdJVK4ow a28s+bUW8boReZEj0L4fdt1KTWhT536ZaDUAZHKmYccHLROUjO2iw9EKR+yPn50gmq+w 7t8U1fDuBiJa+J5f0X0MMMoLvjQl/W5eK8ZCceIIjnfZGqxwGcblFKjxFq8c1Kch1zcd MVkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=NR1bFXgoDOyerqggjqur4dsgq3hiUlZfeIgwxnPcI1I=; b=lVedWgcWdH26/HWoH1KhY2ouCi8zkKrTRmPhDOcwmLE4xWjxzWnZ8YwyozW/F9Sqoc M/IgZJCwQLvFF8aRCMRGJEqkeoy4bqOcVKpmmDPMaKzCdl77H3ouAKwhvlphRC2x7DuY jHl4K5UclSu38L2pjziEYrF5w+Dm1u8tzOlAxexc4JBK2jEC+EsJsu7nHckXRg7scIis 2z4vQE9zC4NUle4iq4p+7/0U9U57gVquXi53DrGoqc7cmLMXzWaFNTN66k3Utr8PxfN9 myFlLwUH8gKUdFC1+Ow82ny/7GUItPzI/aHa5n+hrJKK1VoFrxAW4ulYcudy9cDeqwA1 V2Kw== X-Gm-Message-State: AD7BkJKiTO9jNUC1GJZuNF/+Q+Bu600zholXPn01YvJ2Xnxch1BkiT9J2U1qea61fH+R5g== X-Received: by 10.28.87.65 with SMTP id l62mr34475045wmb.102.1460580555592; Wed, 13 Apr 2016 13:49:15 -0700 (PDT) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id ys9sm40248240wjc.35.2016.04.13.13.49.13 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Apr 2016 13:49:14 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 In-Reply-To: <87oa9dzgl0.fsf@gmx.de> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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" Xref: news.gmane.org gmane.emacs.bugs:116443 Archived-At: Hey Michael, On 04/13/2016 06:14 PM, Michael Albinus wrote: > vc-working-revision shall return nil for unregistered files. vc-state > shall return a non-nil value, 'unregistered. That sounds fine to me in principle, but I don't think we can get there for Emacs 25.1, without paying with lower performance (*). The current code is slower than what's in 24.5 already, as a result of the aforementioned revision. > You cannot guarantee this. Anybody is free to call the functions with > unregistered files.And in the vc-state case, it is even documented that > this could happen. Both true. However, that vc-state's behavior has been different from its documentation in this regard, for many releases. >> In particular, it breaks an assumption I made when fixing #11757, that >> vc-git-state never receives an unregistered file as input. So if you >> evaluate (vc-state "1") now, it'll return `up-to-date'. > > This assumption could be kept if vc-state filters such unregistered > files out. Problem: vc-registered is slower than vc-backend. Like, orders of magnitude slower. vc-backend caches the result of the previous vc-registered invocation in vc-file-prop-obarray. But if we call vc-registered directly, we go the whole way each time, including calling vc-BACKEND-registered. Yes, both vc-state and vc-working-revision cache their results in a property, so we're only paying the added overhead when the file is opened, reverted, etc, but it's still a price. Don't you think it is a problem? > I've prepared a patch which just covers the case that a file is > unregistered, in both vc-state and vc-working-revision. It is a very > small change, that I believe it could still go into the emacs-25 branch. Aside from the above, is there a reason to keep using vc-responsible-backend instead of vc-backend, in vc-state and vc-working-revision? It's also slower than vc-backend. (*) If you _really_ think that vc-state should ever return `unregistered' (personally, I've never found that distinction useful; we could just as well update the docstring that it returns nil in that case), I think the way to get that is to make vc-git-registered return non-nil for all files inside Git-controlled repositories, and to make vc-git-state return `unregistered' for unregistered files (and same for other backends). But it would be a bigger change, better suitable for the next release.