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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 38387 in the body.
You can then email your comments to 38387 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Andrii Kolomoiets <andreyk.mad <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; [PATCH] vc-hg: use 'hg summary' to populate vc-dir headers
Date: Tue, 26 Nov 2019 17:16:07 +0200

[Message part 1 (text/plain, inline)]

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.

[0001-vc-hg-use-hg-summary-to-populate-extra-vc-dir-header.patch (application/octet-stream, attachment)]

Message #8 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>, 38387 <at> debbugs.gnu.org
Cc: Daniel Colascione <dancol <at> dancol.org>
Subject: Re: bug#38387: 27.0.50; [PATCH] vc-hg: use 'hg summary' to populate
 vc-dir headers
Date: Wed, 27 Nov 2019 14:30:13 +0200

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.

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

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 38387 <at> debbugs.gnu.org, Andrii Kolomoiets <andreyk.mad <at> gmail.com>
Subject: Re: bug#38387: 27.0.50;
 [PATCH] vc-hg: use 'hg summary' to populate vc-dir headers
Date: Wed, 27 Nov 2019 14:37:32 +0100

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 <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 38387 <at> debbugs.gnu.org, Andrii Kolomoiets <andreyk.mad <at> gmail.com>
Subject: Re: bug#38387: 27.0.50; [PATCH] vc-hg: use 'hg summary' to populate
 vc-dir headers
Date: Wed, 27 Nov 2019 15:56:15 +0200

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.

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

From: "Daniel Colascione" <dancol <at> dancol.org>
To: "Dmitry Gutov" <dgutov <at> yandex.ru>
Cc: 38387 <at> debbugs.gnu.org, Daniel Colascione <dancol <at> dancol.org>,
 Andrii Kolomoiets <andreyk.mad <at> gmail.com>
Subject: Re: bug#38387: 27.0.50; [PATCH] vc-hg: use 'hg summary' to populate
 vc-dir headers
Date: Wed, 27 Nov 2019 10:53:10 -0800

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

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

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

On 27 Nov 2019, at 20:53, Daniel Colascione <dancol <at> 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.

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

From: Andrii Kolomoiets <andreyk.mad <at> gmail.com>
To: 38387 <at> debbugs.gnu.org
Subject: Re: 27.0.50; [PATCH] vc-hg: use 'hg summary' to populate vc-dir
 headers
Date: Thu, 28 Nov 2019 10:20:43 +0200

[Message part 1 (text/plain, inline)]

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

[0001-vc-hg-use-hg-summary-to-populate-extra-vc-dir-header.patch (application/octet-stream, attachment)]

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

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

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.

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.

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

From: Daniel Colascione <dancol <at> dancol.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>, Andrii Kolomoiets <andreyk.mad <at> gmail.com>
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: Sun, 1 Dec 2019 16:53:27 -0800

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.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: 38387 <at> debbugs.gnu.org, Andrii Kolomoiets <andreyk.mad <at> gmail.com>,
 Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#38387: 27.0.50; [PATCH] vc-hg: use 'hg summary' to populate
 vc-dir headers
Date: Sun, 09 Aug 2020 14:36:31 +0200

Daniel Colascione <dancol <at> 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

Previous Next

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