GNU bug report logs - #38387
27.0.50; [PATCH] vc-hg: use 'hg summary' to populate vc-dir headers

Previous Next

Full log

Message #29 received at 38387 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Andrii Kolomoiets <andreyk.mad <at> gmail.com>,
 Daniel Colascione <dancol <at> dancol.org>
Cc: 38387 <at> debbugs.gnu.org
Subject: Re: bug#38387: 27.0.50; [PATCH] vc-hg: use 'hg summary' to populate
 vc-dir headers
Date: Mon, 2 Dec 2019 02:31:06 +0200

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.