Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: [PATCH v3] Add code to Mercurial VCS backend to show topic if there is any.

Manuel Jacob wrote on Sat, 20 Jun 2020 01:31 +0200:
> "Topics" is an experimental concept in Mercurial that augments the
> current branching concept (called "named branches").
> For more information, see the not always up-to-date Mercurial Wiki page
> https://www.mercurial-scm.org/wiki/TopicPlan.
> ---
>  Functions/VCS_Info/Backends/VCS_INFO_get_data_hg | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> diff --git a/Functions/VCS_Info/Backends/VCS_INFO_get_data_hg b/Functions/VCS_Info/Backends/VCS_INFO_get_data_hg
> index cd5ef321d..deeb331a0 100644
> --- a/Functions/VCS_Info/Backends/VCS_INFO_get_data_hg
> +++ b/Functions/VCS_Info/Backends/VCS_INFO_get_data_hg
> @@ -5,7 +5,7 @@
>  setopt localoptions extendedglob NO_shwordsplit
> -local hgbase bmfile branchfile rebasefile dirstatefile mqseriesfile \
> +local hgbase bmfile branchfile topicfile rebasefile dirstatefile mqseriesfile \
>      curbmfile curbm \
>      mqstatusfile mqguardsfile patchdir mergedir \
>      r_csetid r_lrev r_branch i_bmhash i_bmname \
> @@ -27,6 +27,7 @@ mergedir="${hgbase}/.hg/merge/"
>  bmfile="${hgbase}/.hg/bookmarks"
>  curbmfile="${hgbase}/.hg/bookmarks.current"
>  branchfile="${hgbase}/.hg/branch"
> +topicfile="${hgbase}/.hg/topic"
>  rebasefile="${hgbase}/.hg/rebasestate"
>  dirstatefile="${hgbase}/.hg/dirstate"
>  mqstatusfile="${patchdir}/status" # currently applied patches
> @@ -69,6 +70,13 @@ fi
>  # If we still don't know the branch it's safe to assume default
>  [[ -n ${r_branch} ]] || r_branch="default"
> +# Show topic if there is any (the UI for this experimental concept is not yet
> +# final, but for a long time the convention has been to join the branch name
> +# and the topic name by a colon)
> +if [[ -f ${topicfile} && -r ${topicfile} && -s ${topicfile} ]] ; then
> +    r_branch=${r_branch}:$(head -n 1 ${topicfile})
> +fi

I'm happy to read the file directly, despite experimentality, given the
discussion elsethread that you'll propose a corresponding unit test to
the upstream maintainers.

Using $(head) forks, and we try to avoid forks because they're expensive
on some platforms.  In this case, you could use «IFS= read -r REPLY
<$topicfile» instead.  (The construct «$(<foo)», just above the hunk
context, is special-cased to not fork.)

As written, existing set-branch-format hooks would see the ${hook_com[branch]}
input argument set to strings such as "default:mytopic".  Would this
behaviour be expected, or would people rather expect ${hook_com[branch]}
to be set to strings such as "default" even when .hg/topic exists, and
to have a new ${hook_com[foo]} key whose value would be "mytopic" (or
possibly "default:mytopic")?  This would affect the API to hooks but
would not affect the final output.

Speaking of which, have you tested the output with the get-revision
style set?  (Run «zstyle ':vcs_info:hg:*' get-revision true»
interactively or in your zshrc.)  As written, I expect this patch would
result in output such as «default:mytopic:c04503e1dba4:0» with the style
set, compared to «default:c04503e1dba4:0» with the style set in current
master.  I don't see a problem here; just raising the point for

(The latter output can be customised by setting the the hgrevformat and
branchformat styles with the 'zstyle' builtin.  In the examplar output
above, "c04503e1dba4" is %r in hgrevformat; the final "0" is %h in
hgrevformat; "c04503e1dba4:0", as an atomic unit, is %r in branchformat;
and "default"/"default:mytopic" is %b in branchformat.  The whole
shebang is then %b in the formats/actionformats styles.)

Similarly, as written, the %b expando in "formats", "actionformats", and
"branchformat" will always be replaced with a string such as
"default:mytopic".  If someone wants to change the format,¹ they won't
be able to achieve that using zstyle settings alone; they'd have to
write an appropriate vcs_info hook in their zshrc.  What do you think
of, say, making the topic name available as a separate expando in
branchformat?  Again, this would not affect the default output, but make
customizations easier to implement.

¹ Use-cases for changing the format include: colouring "default" and
"mytopic" differently (compare «zstyle '*' branchformat '%B%b%%b %U%r%u'»
when the get-revision style is set); changing the colon to a space for
readability or copypasteability; and perhaps even eliding the topic
name entirely(?).

>  # The working dir has uncommitted-changes if the revision ends with a +
>  if [[ $r_lrev[-1] == + ]] ; then
>      hgchanges=1



Messages sorted by: Reverse Date, Date, Thread, Author