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#22032: 24.3; VC doesn't handle hg hidden revisions Date: Wed, 16 Dec 2015 02:03:14 +0200 Message-ID: <5670AA42.4090903@yandex.ru> References: <56584054.5080100@gmail.com> <56591524.3010806@yandex.ru> <5659C34E.4070300@gmail.com> <5659EDD4.7030503@yandex.ru> <868u4vxo9n.fsf@gmail.com> 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 1450224265 29869 80.91.229.3 (16 Dec 2015 00:04:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 16 Dec 2015 00:04:25 +0000 (UTC) To: Andy Moreton , 22032@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Dec 16 01:04: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 1a8zZj-0005Dp-1z for geb-bug-gnu-emacs@m.gmane.org; Wed, 16 Dec 2015 01:04:11 +0100 Original-Received: from localhost ([::1]:39646 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a8zZi-0007EM-Db for geb-bug-gnu-emacs@m.gmane.org; Tue, 15 Dec 2015 19:04:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44918) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a8zZf-0007ED-GB for bug-gnu-emacs@gnu.org; Tue, 15 Dec 2015 19:04:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a8zZa-0001HN-HB for bug-gnu-emacs@gnu.org; Tue, 15 Dec 2015 19:04:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:45450) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a8zZa-0001HI-Dy for bug-gnu-emacs@gnu.org; Tue, 15 Dec 2015 19:04:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1a8zZa-0000QR-2v for bug-gnu-emacs@gnu.org; Tue, 15 Dec 2015 19:04:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Dec 2015 00:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22032 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 22032-submit@debbugs.gnu.org id=B22032.14502242041592 (code B ref 22032); Wed, 16 Dec 2015 00:04:02 +0000 Original-Received: (at 22032) by debbugs.gnu.org; 16 Dec 2015 00:03:24 +0000 Original-Received: from localhost ([127.0.0.1]:53052 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1a8zYy-0000Pc-K8 for submit@debbugs.gnu.org; Tue, 15 Dec 2015 19:03:24 -0500 Original-Received: from mail-wm0-f41.google.com ([74.125.82.41]:34075) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1a8zYw-0000PP-Ub for 22032@debbugs.gnu.org; Tue, 15 Dec 2015 19:03:23 -0500 Original-Received: by mail-wm0-f41.google.com with SMTP id l126so17147080wml.1 for <22032@debbugs.gnu.org>; Tue, 15 Dec 2015 16:03:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=pXskMZc9h+YgDzTfdo1bECVAxGKDZV6rlz8SqpXVdzk=; b=dQAN1jaWKhp5UOPDkivxITODkcuNh2WqN+HATNsm81DkjHTJ2HB+VwInw9EvBsQxNe ecSWfYcagdUWaPzZ8xV8fbCFM3b5XcNqNdXfh403LU++U3qwLRig8Lou7kGuAYN9DODc uJmOXnzFzdFKaRTtK2vf82U2/iDluEnCOQIQx1dp5kIM2qAtGO8CVXVCf0+aC2R1ja49 A+H+tz8tP+lPr2ZGGIFjh+IwGV4HHOK2+kzGCDxiNwH/EkubU1KOTyW3FOJKHo7o8CCW dIw3ic2ykS652PGuSifLjOQanq1BUWrgQY7HTf+9Lb4lQ6/0ZHrKeyguZt+mnXGMQdf6 Fo1Q== X-Received: by 10.194.114.34 with SMTP id jd2mr47699091wjb.12.1450224197160; Tue, 15 Dec 2015 16:03:17 -0800 (PST) Original-Received: from [10.9.0.103] (nat.webazilla.com. [78.140.128.228]) by smtp.googlemail.com with ESMTPSA id v129sm22263984wmg.21.2015.12.15.16.03.15 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Dec 2015 16:03:16 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Thunderbird/42.0 In-Reply-To: <868u4vxo9n.fsf@gmail.com> 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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:110039 Archived-At: On 12/16/2015 01:53 AM, Andy Moreton wrote: > This problem with revision IDs also accurs if the repo contains named > branches. in that case the numerically previous revision may be on a > different branch, resulting in a meaningless diff that is slow to > compute. So it's a bug in the current implementation, even without hidden revisions? I'll try to remember this next time someone tells me about user-friendliness of numeric revisions. :) > For example (from a non-public repo with named branches), where rev > 59951 and rev 59950 are on different named branches: > $ hg diff -r59951 -r59950 | wc -l > 88188 > $ hg diff -r59951 -r59951^ | wc -l > 70 > $ hg id -n -r59951^ > 59925 > > The first example diffs agaist the previous revision ID (which is on a > different branch), and produces large and useless diff output. The second > example diffs against the (first) parent, and is what is actually wanted. If there's a direct counterpart to 'git rev-parse 59951^', it would be handy here. > To also work with named branches, something like this (untested) would be better: > (format "last(ancestors(%d) and not hidden())" newrev) So, what if we don't pass "--hidden" to this command? Will `ancestors' error out upon encountering a hidden revision, or will they skip to the first visible one? In the latter case, there's no need to check 'not hidden()', and the compatibility problem can be solved like that.