Viability of Mercurial as an alternative to Git in 2024?

Fri Sep 20 14:10:57 UTC 2024

I see that Jujutsu is getting a slot at Git Merge, God willing one day from
Mercurial!

https://github.com/git/git-merge

On Mon, Sep 16, 2024 at 11:33 AM Pierre-Yves David <
pierre-yves.david at ens-lyon.org> wrote:

>
> On 7/19/24 14:28, PIERRE AUGIER wrote:
>
> I first wanted to react to a statement on Mercurial wheels on PyPI and it leads me to express my fear that Mercurial is not evolving towards a nice alternative to Git.
>
> I describe few issues and try to think about what could be done to fix them.
>
> ----- Mail original -----
>
> De: "Alessandro Dentella" <sandro.dentella at gmail.com> <sandro.dentella at gmail.com>
> À: "Uwe Brauer" <oub at mat.ucm.es> <oub at mat.ucm.es>, "mercurial" <mercurial at mercurial-scm.org> <mercurial at mercurial-scm.org>
> Envoyé: Vendredi 19 Juillet 2024 09:36:14
> Objet: Re: ubuntu 24 (and most likely debian 12) does not allow to install evolve
>
> Il giorno gio 18 lug 2024 alle ore 16:45 Uwe Brauer via Mercurial < [mailto:mercurial at lists.mercurial-scm.org <mercurial at lists.mercurial-scm.org> | mercurial at lists.mercurial-scm.org ]
>
> ha scritto:
>
> II don't really know which version of hg-git is ok for you, but I'm on Ubuntu
> 24:04 and I can tell you that 67.2 is the default that in fact does not work
> with evolve, so Idid exactly what was suggested by Sietze Browser::
>
> sudo apt install pipx
> pipx install mercurial
> pipx inject mercurial hg-evolve hg-git
>
> and I ended up with::
>
> mercurial 6.8
> hg-git 1.1.3
> evolve 11.1.4
>
> do you need something different?
> It was very fast as it uses wheels
>
> Unfortunately, there is no Mercurial wheels on PyPI (see https://pypi.org/project/mercurial/#files)! I don't know any other big public open-source Python projects using extensions that do not upload wheels on PyPI. Nowadays, it is very simple.
>
>
> Yes, we should start to upload wheels, it would even be a powerful tool to
> ship the rust powered improvement to more people.
>
> A few year back, Boris did the necessary work to have wheel easily built
> with docker. However at the time, it was never integrated with the release
> process. In addition, we will need Windows wheel that I believe are of most
> interest to you.
>
>
> Even if I don't like it, I have to admit that it becomes more and more difficult to defend Mercurial. I start to feel that it does not make sense to teach Mercurial anymore. I see two main issues:
>
> 1. Setting up Mercurial with basic extensions (topics, hg-git, evolve) is TOO difficult and long for beginners (in particular compared to Git).
>
> Python packaging is improving but Mercurial does not follow. Installation via pipx really makes sense for Mercurial and its extensions.
>
>
> We are clearly behind in terms of upgrading Mercurial packaging. It is
> fairly complex and the change to Python packaging have been huge overtime.
> Making the endeavor complex. However this tech debt is catching up on us
> fast. If anyone in the community is brave and familiar enough with Python
> packaging wants to tackle it would be of great value.
>
>
> pipx install mercurial
> pipx inject mercurial hg-evolve hg-git
>
> should work **without compilation** (i.e. without Python headers and compilers) basically everywhere/everytime (of course on up-to-date/standard platforms with an up-to-date python). It should be checked that these commands lead to something reasonable on recent Windows, macOS and popular Linux distros. For example, on Windows, I thing there is by default neither vi nor any pager. Mercurial should be aware of that and at least print reasonable advice when such issues are detected.
>
> The commands should lead to a correct user experience, in particular with an easy way to enable tab completion on popular terminals/shells. Modern mercurial should have a command to setup completion (something like https://pixi.sh/latest/#autocompletion).
>
>
> This auto-complete approach seems great. We should do that. (we already
> have auto-completion in `contrib/` we should make them part of python
> package and implement this kind of auto-completion setup command. It could
> also apply to setting up "smart prompt".
>
>
> Using /usr/bin/python3 -m pip install (--user) or --break-system-packages are really bad practice.
>
>
> Agree that these time are behind us. However, mercurial can be installed
> in many different way, making it hard to provide  a "standard" recommended
> way to install extensions.
>
> As we discussed last year in Paris, I believe it would be a reasonable
> amount of work  to add a couple of command dedicated to extensions
> management to Mercurial. Since Mercurial known how and where it is
> installed, it is best suited to deal with that.
>
> I did a very crude PoC of that when I got back from vacation
> https://foss.heptapod.net/mercurial/mercurial-devel/-/merge_requests/930
>
> Note that when combining this idea  with automated config writing
> discussed later in the this email, such command could both install and
> enable an extension in a single command.
>
>
> Using hg-git or topics should not require writing by hands strange lines in ~/.hgrc. It is too difficult for beginners (terminal editors are hard for them) and for teaching it's sure that few students will do it wrong and get a buggy behavior. Nowadays, I wonder if hg-git and topics could not be automatically activated if they are installed for the Python used by Mercurial? Is there a good reason not to do that? It would be possible directly after `pipx inject mercurial hg-evolve hg-git` to clone Mercurial repositories using topics and Git repositories from Github.
>
>
> Unfortunately topic is not ready to be enabled by default yet. It has
> performance and user experience impact that are not suitable for it yet.
> However the plan for topic is to keep fixing theses and to directly
> integrate it as part of Core are we progress. Notably, the current plan for
> topic UX will be a way to smoothly integrate the exchange of draft
> changesets in the core workflow without breaking BC.
>
> Note that we did various small improvement to improve the "raw" situation
> however. For example client not using topic will no longer clone and pull
> changeset on a topic by default, avoiding some of the confusion.
>
>
> If it does not make sense to auto activate topics and hg-git, Mercurial should have a simple interface (command line or maybe something like what we get with `hg commit -i`) to modify its user configuration.
>
> More generally, with Git, one can run `git config --global user.name "Mona Lisa"`, which is convenient for beginners (much more than editing a file).
>
>
> Changing config without manually editing files have been a long standing
> topic for Mercurial. The main issue being the complexity of mixing
> automated and human edit.
>
> However, there is actually a quite simple solution to this issue. We could
> have a config file dedicated to automated changes independent from the one
> targeted to human. The human one would take priority and the command that
> manipulate the config would warn if the "human" config shadow the "machine"
> value set through it. For the new file to be taken in account by older
> Mercurial version, it must be "%included" from the historic one.
>
> To details a bit this would mean :
>
>    - introduce a `hg config --set foo.bar my-value` command (UI may
>    varies),
>    - that command write `.hg/auto.rc` file, that explicitly state that is
>    machine managed (path varies depending config level),
>    - that command ensure that the first line of `.hg/hgrc` is `%include
>    ./auto.rc # some explanatory comment`
>    - If `foo.bar` as a value in `.hg/hgrc` it override the newly set from
>    the command in `.hg/auto.rc`, the command will warn about it.
>
> With this approach we could finally have a programmatic way to set config,
> greatly improving the situation.
>
>
>
> 2. the difference between modern mercurial with topics and hg-git with bookmarks is an issue. We should not need to use/teach bookmarks to interact with a Git repository. Topics are much better. Most Git branches on Github which are not called master or main should be represented by topics (of course, there are exceptions which should be handled). I know that Dan Villiom Podlaski Christiansen works on a topic on this feature (https://foss.heptapod.net/mercurial/hg-git/-/merge_requests/101), which is planed for hg-git 2.0.0. However, I start to be less confident that it will be one day usable.
>
> Moreover phases should be by default reasonable when working with Git repos (at least commits pushed on main/master should be public).
>
>
> Sorry to tell all these negative statements but I feel that without changes and more focus on usability for beginners, I will have to stop to communicate on Mercurial and teach Mercurial. If this is a matter of founding, I may be able to help a bit and more generally we should organize ourself to get enough money to get these improvements.
>
>
> Thanks for you feedback, they highlight area were we could do much better
> by combining new ideas and more attentions. Pointed them will help the
> project to improves
>
> At Octobus, we have been lacking "free" time in the past couple of year,
> but we have been in the process of changing things in order to regain some.
> Funding never hurt in that regard as it help to divers time from other paid
> work or to task other with doing so.
>
> Regards
>
> --
> Pierre-Yves David
>
> _______________________________________________
> Mercurial mailing list
> Mercurial at lists.mercurial-scm.org
> https://lists.mercurial-scm.org/mailman/listinfo/mercurial
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20240920/f079924b/attachment.html>