Viability of Mercurial as an alternative to Git in 2024?

[David Demelier]

> On 19 Jul 2024, at 14:28, PIERRE AUGIER <pierre.augier at univ-grenoble-alpes.fr> 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>
>> À: "Uwe Brauer" <oub at mat.ucm.es>, "mercurial" <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 ]
>>> 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. 
> 
> 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).

There are various areas in which we can tell the same thing like asking a Windows user to switch to Linux. Market share is the prominent reason why people use Git rather than Mercurial. If Bitbucket didn't drop Mercurial support we could still have popular projects on it.

The problem isn't Mercurial nor Git. It's the fact that Git became the "standard" and that  other tools are considered legacy. Learning Perl in 2024 could be something similar, it's less popular while still active that everyone wants to write Python instead. But that does not make Perl out of date for people who still wants to write with that language as long as it's maintained.

Sure being Mercurial advocate since 2009 I'm feeling bad about updating the page "Projects using Mercurial" and seeing that everyone leaves. But that's it, I still use it and until the project itself disappears I'll continue to use it just because I like to gently "piss off" newcomers coming to me telling they can't contribute to my projects because they don't know Mercurial or because I'm not on GitHub/GitLab. I remember two decades ago that people used to contribute to FOSS projects before GitHub was a thing and now they all blame if you don't use it. In fact, it's just not even Git that is popular, it's the platforms. Some contributors are still preventing their contributions to projects not based on GitHub such as Linux kernel or others because they don't even have a clue what a patch actually is.

> Python packaging is improving but Mercurial does not follow. Installation via pipx really makes sense for Mercurial and its extensions.

I don't know for you all but I always used the package manager of my system to install Mercurial with no issue whatsoever. I consider non-distributed extensions as experimental and yes in 15 years of Mercurial use, I'm still not using evolve nor topics.

> 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).

Well, convenient and Git in the same sentence is somewhat strange. Git is far from being convenient in any shape of form. I'm still unable to understand how people could like to use this tool and the trillions of options the command git commit has. I seriously don't estimate git config has a superior feature over Mercurial. Each time a coworker has an issue we're not sure how long we will have to figure it out and how many long-options I'll need to pass to Git history editing commands.

My own .hgrc didn't move in 10 years. Editing a configuration file from code is annoying and complicated which to me is not really needed. If we start thinking of that then vim, tmux, zsh, and all others should offer command line configuration edition too.

Mercurial and Git are developer tools, it's not like they target general users. Starting a project usually comes with editing various files like .editorconfig, .gitignore, .hgignore, .gitlab-ci.yml and so on. I consider adding three lines to a .hgrc as a same exercise.

-- 
David