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 7135 invoked from network); 17 Jun 2020 08:28:32 -0000 Received: from ns1.primenet.com.au (HELO primenet.com.au) (203.24.36.2) by inbox.vuxu.org with ESMTPUTF8; 17 Jun 2020 08:28:32 -0000 Received: (qmail 3251 invoked by alias); 17 Jun 2020 08:28:25 -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: X-Seq: 46052 Received: (qmail 12334 invoked by uid 1010); 17 Jun 2020 08:28:25 -0000 X-Qmail-Scanner-Diagnostics: from wout5-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.21):SA:0(-2.6/5.0):. Processed in 3.636442 secs); 17 Jun 2020 08:28:25 -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: gggruggvucftvghtrhhoucdtuddrgeduhedrudejvddgtdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkjghfofggtgfgsehtqh dttdertdejnecuhfhrohhmpeffrghnihgvlhcuufhhrghhrghfuceougdrshesuggrnhhi vghlrdhshhgrhhgrfhdrnhgrmhgvqeenucggtffrrghtthgvrhhnpeektdefleegvefhue efteeifeevudekgfehgeevfeduffetledvtedvffdvueekudenucffohhmrghinhepmhgv rhgtuhhrihgrlhdqshgtmhdrohhrghenucfkphepjeelrddujeeirdefledrieelnecuve hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepugdrshesuggr nhhivghlrdhshhgrhhgrfhdrnhgrmhgv X-ME-Proxy: Date: Wed, 17 Jun 2020 08:27:43 +0000 From: Daniel Shahaf To: Manuel Jacob Cc: zsh-workers@zsh.org Subject: Re: [PATCH] Add code to Mercurial VCS backend to show topic if there is any. Message-ID: <20200617082743.12b5d092@tarpaulin.shahaf.local2> In-Reply-To: <20200609223416.59a43074@tarpaulin.shahaf.local2> References: <20200607074445.7723-1-me@manueljacob.de> <20200607121443.7c58ee16@tarpaulin.shahaf.local2> <20200608053140.33e79354@tarpaulin.shahaf.local2> <538786d4a3afe4b9432a1469ebafcad8@manueljacob.de> <20200609223416.59a43074@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 Good morning Manuel, Is this still somewhere on your todo list? Any questions to us? No rush. Cheers, Daniel Daniel Shahaf wrote on Tue, 09 Jun 2020 22:34 +0000: > Manuel Jacob wrote on Tue, 09 Jun 2020 03:15 +0200: > > On 2020-06-08 07:31, Daniel Shahaf wrote: =20 > > > Manuel Jacob wrote on Sun, 07 Jun 2020 15:31 +0200: =20 > > >> Hi Daniel, > > >>=20 > > >> On 2020-06-07 14:14, Daniel Shahaf wrote: =20 > > >> > Manuel Jacob wrote on Sun, 07 Jun 2020 09:44 +0200: =20 > > >> >> "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. =20 > > >> > > > >> > I assume "experimental" means "future releases of Mercurial are not > > >> > promised to be backwards compatible with the current design". =20 > > >>=20 > > >> It is not yet part of Mercurial itself, but developed separately as = an > > >> extension under the Mercurial project roof. > > >> =20 > > >=20 > > > Thanks for the info. In practice, though, it doesn't make that much > > > difference to vcs_info whether the functionality lives in Mercurial=20 > > > core > > > or in an extension developed by the same development team. I was more > > > concerned with whether the current on-disk data format is promised to= =20 > > > be > > > supported by future releases of the functionality [whether those be in > > > hg core or in extensions]. > > > =20 > > >> > Is the .hg/topic file name and data format set in stone yet? > > >> > > > >> > What if zsh 5.9 is released and then the Mercurial developers chan= ge > > >> > the design to make .hg/topic a directory, and release _that_? Then > > >> > everyone who uses zsh 5.9 with hg will be stuck with vcs_info erro= rs > > >> > until their distro upgrades to newer zsh. =20 > > >>=20 > > >> The .hg/topic file works very similar to the .hg/branch file (which = is > > >> stable since 2007 and which zsh currently depends on). I can't think= =20 > > >> of > > >> any reason why someone would consider changing the format. > > >> =20 > > >=20 > > > I'm not going to second-guess your assessment, but I am surprised by= =20 > > > it. =20 > >=20 > > The main developer of the topic extension said that there will be clear= =20 > > message if it changed. When I asked him "do you think it is safe for a= =20 > > shell prompt hook to depend on the .hg/topic file name and data=20 > > format?", the answer was "safe enough". What he considers "safe enough"= =20 > > might not be "safe enough" for zsh. =20 >=20 > Thanks for going to the horse's mouth. Yes, "safe enough" is a bit > vague. >=20 > > As a zsh user, I find it reassuring that the standards for inclusion ar= e high. =20 >=20 > Thanks for your understanding and for making it explicit =E2=98=BA >=20 > > >> The file would only be created if a user installs and activates the > > >> extension, and explictly creates a topic (a specific kind of feature > > >> branch), so that makes it even more unlikely that something breaks. = =20 > > >=20 > > > I do see that if topics are not popular, then the probability that > > > a random hg user would be affected by a forward incompatible assumpti= on > > > in vcs_info is low. However, users of hg topics that uses vcs_info > > > _would_ be affected and would have no easy workaround. > > >=20 > > > Furthermore, it is zsh, not hg, who would receive the consequent bug > > > reports and negative word-of-mouth. > > >=20 > > > Could you comment on what options are there to design forward > > > compatibility into the patch? It would be good to lay out=20 > > > alternatives, > > > even if we don't end up implementing any of them. =20 > >=20 > > One option is that people would have to opt-in to get the topic shown.= =20 > > This way, people could be made aware that they=E2=80=99re using somethi= ng that=20 > > could break in the future. However, I don=E2=80=99t know whether zsh pr= ovides a=20 > > framework for having this kind of configuration. > > =20 >=20 > Configurability could be provided via the 'zstyle' builtin. Briefly, > zstyles map strings ("contexts") to key-to-list-of-words maps by > specifying pattern that contexts are matched against. (See the manual > for details.) A user might do in their zshrc > . > zstyle ':vcs_info:hg:*' experimental-features topic > . > and then the vcs_info backend would run =C2=ABzstyle -a=C2=BB and get an = array > =C2=ABreply=3D( topic )=C2=BB. Without that zshrc setting, the array wou= ld be > empty. >=20 > There should be plenty of examples of this in vcs_info, and more in the > completion system. >=20 > > The hook could check harder that the .hg/topic file is in the expected= =20 > > format, e.g. checking that it is a regular file. As long as it=E2=80=99= s a=20 > > regular file, I=E2=80=99d consider it a gross violation of the user exp= ectation=20 > > if the file contained anything other than simply the topic name. > > =20 >=20 > Makes sense. This way, if there _is_ an upstream backwards-incompatible > change [which is fine, of course, in an experimental feature], the > fallout would be minimal. >=20 > Or maybe vcs_info could read just the first line of the file. This > way, if future hg adds more info in subsequent lines, we'll be forward > compatible with that. >=20 > > I could submit the diff of this patch for inclusion in the "contrib"=20 > > directory of the topic extension repository to remind them that people= =20 > > depend on the file name and data format. =20 >=20 > Making upstream aware that it has downstreams that depend on the data > format would definitely be a Good Thing. A contrib patch wouldn't have > been my first choice, though: I'd rather recommend creating a unit test > that creates and reads a topic in the same way vcs_info will, with > a comment explaining that (and a comment in vcs_info that points to the > test). >=20 > Or perhaps the vcs_info hg backend should be maintained as part of hg? > That would require vcs_info to provide a public API for third-party > backends. >=20 > Cheers! >=20 > Daniel