From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 3299 invoked from network); 21 Jun 2020 12:26:43 -0000 Received: from ns1.primenet.com.au (HELO primenet.com.au) (203.24.36.2) by inbox.vuxu.org with ESMTPUTF8; 21 Jun 2020 12:26:43 -0000 Received: (qmail 27116 invoked by alias); 21 Jun 2020 12:26:34 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: Sender: zsh-workers@zsh.org X-Seq: 46089 Received: (qmail 27499 invoked by uid 1010); 21 Jun 2020 12:26:33 -0000 X-Qmail-Scanner-Diagnostics: from wout1-smtp.messagingengine.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.3/25842. spamassassin: 3.4.4. Clear:RC:0(64.147.123.24):SA:0(-2.6/5.0):. Processed in 4.567602 secs); 21 Jun 2020 12:26:33 -0000 X-Envelope-From: d.s@daniel.shahaf.name X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at daniel.shahaf.name does not designate permitted sender hosts) X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudektddgheehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkjghfofggtgfgsehtqh dttdertdejnecuhfhrohhmpeffrghnihgvlhcuufhhrghhrghfuceougdrshesuggrnhhi vghlrdhshhgrhhgrfhdrnhgrmhgvqeenucggtffrrghtthgvrhhnpeektdefleegvefhue efteeifeevudekgfehgeevfeduffetledvtedvffdvueekudenucffohhmrghinhepmhgv rhgtuhhrihgrlhdqshgtmhdrohhrghenucfkphepjeelrddujeeirdefledrieelnecuve hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepugdrshesuggr nhhivghlrdhshhgrhhgrfhdrnhgrmhgv X-ME-Proxy: Date: Sun, 21 Jun 2020 12:25:46 +0000 From: Daniel Shahaf To: Manuel Jacob Cc: zsh-workers@zsh.org Subject: Re: [PATCH v3] Add code to Mercurial VCS backend to show topic if there is any. Message-ID: <20200621122546.4272f43f@tarpaulin.shahaf.local2> In-Reply-To: References: <20200619233112.191102-1-me@manueljacob.de> <20200620104317.51bac64a@tarpaulin.shahaf.local2> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Manuel Jacob wrote on Sun, 21 Jun 2020 13:17 +0200: > On 2020-06-20 12:43, Daniel Shahaf wrote: > > 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"). > >>=20 > >> For more information, see the not always up-to-date Mercurial Wiki=20 > >> 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(-) > >>=20 > >> diff --git a/Functions/VCS_Info/Backends/VCS_INFO_get_data_hg=20 > >> 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 @@ > >>=20 > >> setopt localoptions extendedglob NO_shwordsplit > >>=20 > >> -local hgbase bmfile branchfile rebasefile dirstatefile mqseriesfile \ > >> +local hgbase bmfile branchfile topicfile rebasefile dirstatefile=20 > >> mqseriesfile \ > >> curbmfile curbm \ > >> mqstatusfile mqguardsfile patchdir mergedir \ > >> r_csetid r_lrev r_branch i_bmhash i_bmname \ > >> @@ -27,6 +27,7 @@ mergedir=3D"${hgbase}/.hg/merge/" > >> bmfile=3D"${hgbase}/.hg/bookmarks" > >> curbmfile=3D"${hgbase}/.hg/bookmarks.current" > >> branchfile=3D"${hgbase}/.hg/branch" > >> +topicfile=3D"${hgbase}/.hg/topic" > >> rebasefile=3D"${hgbase}/.hg/rebasestate" > >> dirstatefile=3D"${hgbase}/.hg/dirstate" > >> mqstatusfile=3D"${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=3D"default" > >>=20 > >> +# Show topic if there is any (the UI for this experimental concept is= =20 > >> not yet > >> +# final, but for a long time the convention has been to join the=20 > >> branch name > >> +# and the topic name by a colon) > >> +if [[ -f ${topicfile} && -r ${topicfile} && -s ${topicfile} ]] ; then > >> + r_branch=3D${r_branch}:$(head -n 1 ${topicfile}) > >> +fi > >=20 > > 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. > >=20 > > Using $(head) forks, and we try to avoid forks because they're=20 > > expensive > > on some platforms. In this case, you could use =C2=ABIFS=3D read -r RE= PLY > > <$topicfile=C2=BB instead. (The construct =C2=AB$( > context, is special-cased to not fork.) >=20 > Is there anything special about `REPLY`? It seems to be a convention.=20 > Could I also use e.g. TOPIC? Yes, $REPLY is merely a convention (see zshparam(1)). You could use $topic (lowercase) instead; $TOPIC (uppercase) would not be idiomatic. > > As written, existing set-branch-format hooks would see the=20 > > ${hook_com[branch]} > > input argument set to strings such as "default:mytopic". Would this > > behaviour be expected, or would people rather expect=20 > > ${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. >=20 > If the topic extension is enabled, the meaning of places using branch=20 > names is changed. > When determining how many heads a branch has (e.g. when warning that=20 > another head will be created), each "branch:topic" (or simply "branch"=20 > if there=E2=80=99s no topic) is considered separately. > When specifying a revision, "branch:topic" refers to the head of the=20 > branch with branch name "branch" and topic name "topic", while "branch"=20 > refers to the headmost revision with branch name "branch" but no topic. >=20 > An example: >=20 > B C > |/ > A >=20 > Assume that all three changesets have the "branch" field set to=20 > "develop". B has topic "feature1" and C has topic "feature2". >=20 > * "develop" refers to A > * "develop:feature1" refers to B > * "develop:feature2" refers to C >=20 > If the user updated to B, but the prompt shows "develop" (this is=20 > currently the case), it would be misleading. I don=E2=80=99t know all=20 > possibilities in which the hooks use `${hook_com[branch]}`, but I=E2=80= =99d=20 > expect that including the topic would be correct in more cases than not=20 > including it. >=20 Thanks for the walkthrough. Agreed. Might want to state on Doc/Zsh/contrib.yo:1331 that in the hg backend the topic is included, then. > > Similarly, as written, the %b expando in "formats", "actionformats",=20 > > and > > "branchformat" will always be replaced with a string such as > > "default:mytopic". If someone wants to change the format,=C2=B9 they w= on'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=20 > > make > > customizations easier to implement. > >=20 > > =C2=B9 Use-cases for changing the format include: colouring "default" a= nd > > "mytopic" differently (compare =C2=ABzstyle '*' branchformat '%B%b%%b=20 > > %U%r%u'=C2=BB > > 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(?). >=20 > For the reasons stated above, the topic name should be included. The=20 > colon should also stay because the combined "branch:topic" can be passed= =20 > as a revision identifier to various places. Coloring branch and topic=20 > differently wouldn=E2=80=99t be "wrong", but since the "branch:topic" mos= tly=20 > makes sense together, personally I=E2=80=99d like to have it in the same= =20 > appearance. I see: if "branch:topic" mostly appears as an atomic unit, it makes sense that most people will want to color it atomically. > That's all, I think. I don't foresee any blocks to merging v4 when you post it. Cheers, Daniel