Zsh Mailing List Archive
Messages sorted by:
Re: [PATCH] Add code to Mercurial VCS backend to show topic if there is any.
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:
> >> Hi Daniel,
> >> On 2020-06-07 14:14, Daniel Shahaf wrote:
> >> > Manuel Jacob wrote on Sun, 07 Jun 2020 09:44 +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.
> >> >
> >> > I assume "experimental" means "future releases of Mercurial are not
> >> > promised to be backwards compatible with the current design".
> >> It is not yet part of Mercurial itself, but developed separately as an
> >> extension under the Mercurial project roof.
> > Thanks for the info. In practice, though, it doesn't make that much
> > difference to vcs_info whether the functionality lives in Mercurial
> > 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
> > be
> > supported by future releases of the functionality [whether those be in
> > hg core or in extensions].
> >> > 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.
> >> 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
> >> of
> >> any reason why someone would consider changing the format.
> > I'm not going to second-guess your assessment, but I am surprised by
> > it.
> The main developer of the topic extension said that there will be clear
> message if it changed. When I asked him "do you think it is safe for a
> shell prompt hook to depend on the .hg/topic file name and data
> format?", the answer was "safe enough". What he considers "safe enough"
> might not be "safe enough" for zsh.
Thanks for going to the horse's mouth. Yes, "safe enough" is a bit
> As a zsh user, I find it reassuring that the standards for inclusion are high.
Thanks for your understanding and for making it explicit ☺
> >> 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.
> > 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.
> > Furthermore, it is zsh, not hg, who would receive the consequent bug
> > reports and negative word-of-mouth.
> > Could you comment on what options are there to design forward
> > compatibility into the patch? It would be good to lay out
> > alternatives,
> > even if we don't end up implementing any of them.
> One option is that people would have to opt-in to get the topic shown.
> This way, people could be made aware that they’re using something that
> could break in the future. However, I don’t know whether zsh provides a
> framework for having this kind of configuration.
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 «zstyle -a» and get an array
«reply=( topic )». Without that zshrc setting, the array would be
There should be plenty of examples of this in vcs_info, and more in the
> The hook could check harder that the .hg/topic file is in the expected
> format, e.g. checking that it is a regular file. As long as it’s a
> regular file, I’d consider it a gross violation of the user expectation
> if the file contained anything other than simply the topic name.
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"
> directory of the topic extension repository to remind them that people
> 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
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
Messages sorted by: