Viability of Mercurial as an alternative to Git in 2024?

Mon Sep 16 08:25:27 UTC 2024

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>
>> À: "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 (seehttps://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 likehttps://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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20240916/f4561871/attachment.html>