From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.bugs Subject: bug#38387: 27.0.50; [PATCH] vc-hg: use 'hg summary' to populate vc-dir headers Date: Sun, 1 Dec 2019 16:53:27 -0800 Message-ID: References: <7505dd70-86c1-9576-5dc9-42b1abca519e@yandex.ru> <0366bc0bf7f7c65bdc5e869397d4c945.squirrel@dancol.org> <4b1cce9f-b6b7-4d03-00e2-118cb7f8dbb5@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="206858"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 Cc: 38387@debbugs.gnu.org To: Dmitry Gutov , Andrii Kolomoiets Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Dec 02 01:54:22 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1ibZym-000rgr-Tk for geb-bug-gnu-emacs@m.gmane.org; Mon, 02 Dec 2019 01:54:21 +0100 Original-Received: from localhost ([::1]:57270 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ibZyl-0007YD-Lc for geb-bug-gnu-emacs@m.gmane.org; Sun, 01 Dec 2019 19:54:19 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48147) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ibZyV-0007Vz-NF for bug-gnu-emacs@gnu.org; Sun, 01 Dec 2019 19:54:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ibZyU-00010d-6c for bug-gnu-emacs@gnu.org; Sun, 01 Dec 2019 19:54:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:59146) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ibZyT-00010J-NP for bug-gnu-emacs@gnu.org; Sun, 01 Dec 2019 19:54:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ibZyT-0005Mg-Lq for bug-gnu-emacs@gnu.org; Sun, 01 Dec 2019 19:54:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 02 Dec 2019 00:54:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38387 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 38387-submit@debbugs.gnu.org id=B38387.157524803320605 (code B ref 38387); Mon, 02 Dec 2019 00:54:01 +0000 Original-Received: (at 38387) by debbugs.gnu.org; 2 Dec 2019 00:53:53 +0000 Original-Received: from localhost ([127.0.0.1]:36886 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ibZyK-0005MH-QS for submit@debbugs.gnu.org; Sun, 01 Dec 2019 19:53:53 -0500 Original-Received: from dancol.org ([96.126.100.184]:43636) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ibZyH-0005M7-Vq for 38387@debbugs.gnu.org; Sun, 01 Dec 2019 19:53:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=v64sBc7xmAusv0rCTKNGGc9hocOxY7KVaOLCKwjooNY=; b=aNlg2uhAmVN9nrhYXJkibM1eNC t1RG97QXsXSeW0GHYhoihIVhsbJw7EjUCXTX1USVxXKjCJNPaEaIp1ZxJS9FUqu0Ndfrk1Q2HKh+9 3ac658iQZjCir5/DOUnYDGPUPboZUfXvlMC4dXkjPJJ6VHKdW8Y532vppt4Sslg5ROeKthgQjbSJV v9Csm77DuF4YHRoHC2PMY2rHWPB3pPyV+VVpNDU3X11SuncwjpnrUpGiHIgTnXxXH0z4Vp1avhANX EP/YAX5HP+OrtH/gnL61btKkpUQSG4+NSUwbqVlTzr2qdiuIyy92EZM+zn0lLAI2UokyfXqSidk5N 98EvRIeg==; Original-Received: from [2604:4080:1321:9a00:e13c:266:1dc4:1cfa] by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1ibZyF-000801-Pn; Sun, 01 Dec 2019 16:53:47 -0800 In-Reply-To: <4b1cce9f-b6b7-4d03-00e2-118cb7f8dbb5@yandex.ru> Content-Language: en-US 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: 209.51.188.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:172744 Archived-At: On 12/1/19 4:31 PM, Dmitry Gutov wrote: > On 28.11.2019 10:07, Andrii Kolomoiets wrote: > >> Current output displays current branch and tag. There are also root dir, >> but vc displays working dir itself, so root is not needed. >> BTW root can be replaced with bookmark because bookmark is what >> vc-hg-create-tag create when branchp.  From user's POV the branch >> creation is not working: >> 1. Open vc-dir for hg repository >> 2. C-u B c >> 3. Enter branch name to create >> and nothing changed in vc-dir - branch and tag are remains the same. > > Should it actually created branches instead? Or do Mercurial branches > differ sufficiently from the same concept in other VCS? > > Could anybody say why vc-hg-create-tag has been using bookmarks from the > outset? > >> Info that 'summary' shows but missed in the current output: >> >> - Parent revision and first line of commit message. >>    During merge both parents are shown.  Very handy. >>    This info can be obtained by parsing 'hg log' command output. >> >> - Bookmarks, if any. >>    Can be obtained by 'hg id -B'. >> >> - Commit state. >>    Shows the count of modified, added, removed, renamed, copied, deleted, >>    unknown and unresolved files.  Alright, all affected files are listed >>    in the same vc-dir buffer and one can count them so those numbers may >>    be not very interesting. >>    But commit state also can show if graft, update or merge is in >>    progress; if head are closed; if it is a new branch; if there are >>    changes in subrepositories.  I don't know how to obtain this info. >> >> - Update state. >>    Shows the available updates count and/or branch heads count. >>    I don't know how obtain this info, maybe some log command. >> >> - Number of incoming and outgoing changes (with '--remote' switch). >>    It is slow, but we can allow user to decide use it or not. >> >> - Phase.  Can show how many changesets are not shared yet. >> >> IMO 'summary' gives better overview of repo state. > > I'd like to hear from others about how crucial this info is. > > FWIW, I'm usually okay with the minimal VC-Dir output that vc-git does. > >>>> - Is 'hg summary' stable enough? Maybe a few years from now Mercurial >>>> changes its output and this code stops working in all Emacs we'd have >>>> released in the meantime? This is why we try to use "porcelain" level >>>> commands (in Git terminology) when possible, not user-level. >> >> This code do nothing but propertize the text.  We just show the user the >> output of the user command. > > It would be a shame if it breaks anyway. > >> The layout can be messed though if the name-value separator will be >> changed. To solve this the regexp can be put into the variable so it can >> be changed easily.  Removal of the 'summary' command is the worst case. >> But AFAIK there are no prerequisites for this.  Let's not hide usefull >> info from the user because we affraid of hypothetical removal of the >> 'summary' command :) >> For now, comparing 'summary' output of hg 2.6.2 and 5.2, I can see that >> phase info is added in recent version and no breaking changes at all. > > Moving the regexp into a var could alleviate the biggest part of the > risk, indeed. > >>> What's the performance of summary like these days? >> >> Let's see. >> >>    hg summary  0.21s user 0.16s system 98% cpu 0.376 total >> >>    hg log -r 'p1(.)+p2(.)'  0.14s user 0.08s system 99% cpu 0.221 total >>    hg id --branch  0.14s user 0.13s system 98% cpu 0.280 total >>    hg id --tags  0.15s user 0.14s system 98% cpu 0.299 total >>    hg id --bookmarks  0.15s user 0.15s system 98% cpu 0.298 total >>    hg phase  0.12s user 0.07s system 97% cpu 0.193 total >> >> Yes, 'summary' is slower than single 'id' command. > > We're not comparing against a single one. Would it be faster than what > we do now? The comparison above seems like it would? > >> But again, it is >> faster to run a single command that gives all the info rather than run >> five different commands. Imagine working with repo over TRAMP. > > TRAMP is an okay argument, too. I care mostly about the latency of visiting individual files. That *must* be fast. If this is something that runs only on vc-dir, that's probably fine.