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

[Andrii Kolomoiets]

On 27 Nov 2019, at 20:53, Daniel Colascione <dancol@dancol.org> wrote:
> 
>> Hi Andrii,
>> 
>> On 26.11.2019 17:16, Andrii Kolomoiets wrote:
>> 
>>> By invoking single 'summary' command we can get more info about
>>> repository state: parent revisions, current branch, tags, bookmarks,
>>> commit status, available updates and phase.
>> 
>> I guess the questions are:
>> 
>> - Is this output better than the previous one? Hopefully others will
>> chime in, e.g. Daniel, who wrote some major improvements to vc-hg a few
>> years ago.

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.

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.


>> - 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.

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.


> 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. 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.


Best regards.