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 5077 invoked from network); 9 Jun 2020 22:35:18 -0000 Received: from ns1.primenet.com.au (HELO primenet.com.au) (203.24.36.2) by inbox.vuxu.org with ESMTPUTF8; 9 Jun 2020 22:35:18 -0000 Received: (qmail 7448 invoked by alias); 9 Jun 2020 22:35:05 -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: 46032 Received: (qmail 23849 invoked by uid 1010); 9 Jun 2020 22:35:05 -0000 X-Qmail-Scanner-Diagnostics: from out3-smtp.messagingengine.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.3/25835. spamassassin: 3.4.4. Clear:RC:0(66.111.4.27):SA:0(-2.6/5.0):. Processed in 4.398477 secs); 09 Jun 2020 22:35:05 -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: gggruggvucftvghtrhhoucdtuddrgeduhedrudehhedgudduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkjghfofggtgfgsehtqh dttdertdejnecuhfhrohhmpeffrghnihgvlhcuufhhrghhrghfuceougdrshesuggrnhhi vghlrdhshhgrhhgrfhdrnhgrmhgvqeenucggtffrrghtthgvrhhnpeektdefleegvefhue efteeifeevudekgfehgeevfeduffetledvtedvffdvueekudenucffohhmrghinhepmhgv rhgtuhhrihgrlhdqshgtmhdrohhrghenucfkphepjeelrddujeeirdefledrieelnecuve hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepugdrshesuggr nhhivghlrdhshhgrhhgrfhdrnhgrmhgv X-ME-Proxy: Date: Tue, 9 Jun 2020 22:34:16 +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: <20200609223416.59a43074@tarpaulin.shahaf.local2> In-Reply-To: <538786d4a3afe4b9432a1469ebafcad8@manueljacob.de> References: <20200607074445.7723-1-me@manueljacob.de> <20200607121443.7c58ee16@tarpaulin.shahaf.local2> <20200608053140.33e79354@tarpaulin.shahaf.local2> <538786d4a3afe4b9432a1469ebafcad8@manueljacob.de> 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 Tue, 09 Jun 2020 03:15 +0200: > On 2020-06-08 07:31, Daniel Shahaf wrote: > > 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 change > >> > 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 errors > >> > 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. Thanks for going to the horse's mouth. Yes, "safe enough" is a bit vague. > As a zsh user, I find it reassuring that the standards for inclusion are = high. Thanks for your understanding and for making it explicit =E2=98=BA > >> 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 assumption > > 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 something= that=20 > could break in the future. However, I don=E2=80=99t know whether zsh prov= ides a=20 > framework for having this kind of configuration. >=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 ar= ray =C2=ABreply=3D( topic )=C2=BB. Without that zshrc setting, the array would= be empty. There should be plenty of examples of this in vcs_info, and more in the completion system. > 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=99s = a=20 > regular file, I=E2=80=99d consider it a gross violation of the user expec= tation=20 > if the file contained anything other than simply the topic name. >=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. 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. > 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. 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). 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. Cheers! Daniel