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

[Daniel Colascione <dancol@dancol.org>]

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.