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

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

[Andrii Kolomoiets]

[-- Attachment #1: Type: text/plain, Size: 183 bytes --]

Hi,

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.


[-- Attachment #2: 0001-vc-hg-use-hg-summary-to-populate-extra-vc-dir-header.patch --]
[-- Type: application/octet-stream, Size: 3231 bytes --]

From 77350d57f718efbf96d4c8deb59b80e22c2ebea7 Mon Sep 17 00:00:00 2001
From: Andrii Kolomoiets <andreyk.mad@gmail.com>
Date: Tue, 26 Nov 2019 17:10:29 +0200
Subject: [PATCH] vc-hg: use 'hg summary' to populate vc-dir headers

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.

* lisp/vc/vc-hg.el (vc-hg-dir-extra-headers): Use 'hg summary' command.
(vc-hg-dir-extra-header): Remove unused function.
* etc/NEWS: Mention changes to vc-hg.el

diff --git a/etc/NEWS b/etc/NEWS
index d3331daf17..f7abfb1680 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -956,6 +956,10 @@ with conflicts existed in earlier versions of Emacs, but incorrectly
 never detected a conflict due to invalid assumptions about cached
 values.
 
+---
+*** 'vc-hg' now uses 'hg summary' command to populate extra 'vc-dir'
+headers.
+
 +++
 *** The Hg (Mercurial) back-end now supports 'vc-region-history'.
 The 'C-x v h' command now works in buffers that visit files controlled
diff --git a/lisp/vc/vc-hg.el b/lisp/vc/vc-hg.el
index 17d38fa400..6ff4923a14 100644
--- a/lisp/vc/vc-hg.el
+++ b/lisp/vc/vc-hg.el
@@ -1357,25 +1357,28 @@ vc-hg-dir-status-files
   (vc-run-delayed
     (vc-hg-after-dir-status update-function)))
 
-(defun vc-hg-dir-extra-header (name &rest commands)
-  (concat (propertize name 'face 'font-lock-type-face)
-          (propertize
-           (with-temp-buffer
-             (apply 'vc-hg-command (current-buffer) 0 nil commands)
-             (buffer-substring-no-properties (point-min) (1- (point-max))))
-           'face 'font-lock-variable-name-face)))
-
 (defun vc-hg-dir-extra-headers (dir)
-  "Generate extra status headers for a Mercurial tree."
+  "Generate extra status headers for a repository in DIR.
+This runs the command \"hg summary\"."
   (let ((default-directory dir))
-    (concat
-     (vc-hg-dir-extra-header "Root       : " "root") "\n"
-     (vc-hg-dir-extra-header "Branch     : " "id" "-b") "\n"
-     (vc-hg-dir-extra-header "Tags       : " "id" "-t") ; "\n"
-     ;; these change after each commit
-     ;; (vc-hg-dir-extra-header "Local num  : " "id" "-n") "\n"
-     ;; (vc-hg-dir-extra-header "Global id  : " "id" "-i")
-     )))
+    (with-temp-buffer
+      (vc-hg-command t 0 nil "summary")
+      (goto-char (point-min))
+      (mapconcat
+       #'identity
+       (let (result)
+         (while (not (eobp))
+           (push
+            (let ((entry (if (looking-at "\\([^ ].*\\): \\(.*\\)")
+                             (cons (capitalize (match-string 1)) (match-string 2))
+                           (cons "" (buffer-substring (point) (line-end-position))))))
+              (concat
+               (propertize (format "%-11s: " (car entry)) 'face 'font-lock-type-face)
+               (propertize (cdr entry) 'face 'font-lock-variable-name-face)))
+            result)
+           (forward-line))
+         (nreverse result))
+       "\n"))))
 
 (defun vc-hg-log-incoming (buffer remote-location)
   (vc-hg-command buffer 1 nil "incoming" "-n" (unless (string= remote-location "")
-- 
2.15.1

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

[Dmitry Gutov]

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.

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

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

[Andreas Schwab]

On Nov 27 2019, Dmitry Gutov wrote:

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

Git calls them "plumbing".  "Porcelain" are the high-level commands.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

[Dmitry Gutov]

On 27.11.2019 15:37, Andreas Schwab wrote:
> Git calls them "plumbing".  "Porcelain" are the high-level commands.

My mistake, I guess. Git makes terminology a little confusing in that 
part. Because the example I was thinking of is 'git status --porcelain' 
which is meant to

   "Give the output in an easy-to-parse format for scripts. This is
    similar to the short output, but will remain stable across Git
    versions and regardless of user configuration."

In any case, the question is about output's stability.

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

[Daniel Colascione]

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

What's the performance of summary like these days?

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.

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

[Dmitry Gutov]

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.

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

[Daniel Colascione]

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.

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

[Lars Ingebrigtsen]

Daniel Colascione <dancol@dancol.org> writes:

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

If I read this thread correctly, there were no objections to applying
this patch, so I've now done so in Emacs 28.  If that's wrong, feel free
to revert the patch.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Dmitry Gutov]

On 27.11.2019 20:53, Daniel Colascione wrote:
> What's the performance of summary like these days?

Speaking of performance, 'hg summary' on my old mozilla-central checkout 
takes about 1.2 sec. But the current impl is not instantaneous either.

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

[Andrii Kolomoiets]

[-- Attachment #1: Type: text/plain, Size: 118 bytes --]

Patch is slightly modified to match all whitespaces after ':' to handle possible extra spaces in 'summary' output.


[-- Attachment #2: 0001-vc-hg-use-hg-summary-to-populate-extra-vc-dir-header.patch --]
[-- Type: application/octet-stream, Size: 3235 bytes --]

From 77350d57f718efbf96d4c8deb59b80e22c2ebea7 Mon Sep 17 00:00:00 2001
From: Andrii Kolomoiets <andreyk.mad@gmail.com>
Date: Tue, 26 Nov 2019 17:10:29 +0200
Subject: [PATCH] vc-hg: use 'hg summary' to populate vc-dir headers

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.

* lisp/vc/vc-hg.el (vc-hg-dir-extra-headers): Use 'hg summary' command.
(vc-hg-dir-extra-header): Remove unused function.
* etc/NEWS: Mention changes to vc-hg.el

diff --git a/etc/NEWS b/etc/NEWS
index d3331daf17..f7abfb1680 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -956,6 +956,10 @@ with conflicts existed in earlier versions of Emacs, but incorrectly
 never detected a conflict due to invalid assumptions about cached
 values.
 
+---
+*** 'vc-hg' now uses 'hg summary' command to populate extra 'vc-dir'
+headers.
+
 +++
 *** The Hg (Mercurial) back-end now supports 'vc-region-history'.
 The 'C-x v h' command now works in buffers that visit files controlled
diff --git a/lisp/vc/vc-hg.el b/lisp/vc/vc-hg.el
index 17d38fa400..6ff4923a14 100644
--- a/lisp/vc/vc-hg.el
+++ b/lisp/vc/vc-hg.el
@@ -1357,25 +1357,28 @@ vc-hg-dir-status-files
   (vc-run-delayed
     (vc-hg-after-dir-status update-function)))
 
-(defun vc-hg-dir-extra-header (name &rest commands)
-  (concat (propertize name 'face 'font-lock-type-face)
-          (propertize
-           (with-temp-buffer
-             (apply 'vc-hg-command (current-buffer) 0 nil commands)
-             (buffer-substring-no-properties (point-min) (1- (point-max))))
-           'face 'font-lock-variable-name-face)))
-
 (defun vc-hg-dir-extra-headers (dir)
-  "Generate extra status headers for a Mercurial tree."
+  "Generate extra status headers for a repository in DIR.
+This runs the command \"hg summary\"."
   (let ((default-directory dir))
-    (concat
-     (vc-hg-dir-extra-header "Root       : " "root") "\n"
-     (vc-hg-dir-extra-header "Branch     : " "id" "-b") "\n"
-     (vc-hg-dir-extra-header "Tags       : " "id" "-t") ; "\n"
-     ;; these change after each commit
-     ;; (vc-hg-dir-extra-header "Local num  : " "id" "-n") "\n"
-     ;; (vc-hg-dir-extra-header "Global id  : " "id" "-i")
-     )))
+    (with-temp-buffer
+      (vc-hg-command t 0 nil "summary")
+      (goto-char (point-min))
+      (mapconcat
+       #'identity
+       (let (result)
+         (while (not (eobp))
+           (push
+            (let ((entry (if (looking-at "\\([^ ].*\\):\\s-+\\(.*\\)")
+                             (cons (capitalize (match-string 1)) (match-string 2))
+                           (cons "" (buffer-substring (point) (line-end-position))))))
+              (concat
+               (propertize (format "%-11s: " (car entry)) 'face 'font-lock-type-face)
+               (propertize (cdr entry) 'face 'font-lock-variable-name-face)))
+            result)
+           (forward-line))
+         (nreverse result))
+       "\n"))))
 
 (defun vc-hg-log-incoming (buffer remote-location)
   (vc-hg-command buffer 1 nil "incoming" "-n" (unless (string= remote-location "")
-- 
2.15.1