Viability of Mercurial as an alternative to Git in 2024?

[Dr. Arne Babenhauserheide]

Uwe Brauer via Mercurial <mercurial at lists.mercurial-scm.org> writes:
>     1. First a comment on installing mercurial. Yes, the python _thing 
>        is a problem, but in my understanding python itself is the
>        culprit to a certain extend, since backward compatibility was not
>        a mayor goal. (2.7 vs 3.X 3.5 vs 3.10 etc etc). I think when git
>        and hg started, hg was considered as more elegant and cleaner
>        since it used python while git uses C and shell scripts and who
>        knows what else, but who has problems now, is hg not git.

Having fixed two extensions that got broken by Python 3, I now think
that Python 3 did tremendous damage to Mercurial.

It is one of the main reasons why I wrote the article "Volatile
Infrastructure is worse than volatile applications":
https://www.draketo.de/software/volatile-infrastructure
"We cannot stand on the shoulders of giants if we constantly break old tools."

And I think that breakage caused damage to the whole Python environment.

Mercurial was kind of like the poster child of creating an application
that uses Python to the best of its abilities: building everything in
Python except for the few critical hot paths.

With Mercurial broken pretty badly by the change and taking years to
adapt to Python 3, this example seems to have been missing, because the
new Machine Learning tools are written very differently: with a huge C++
backend that’s controlled by a pretty thin layer of Python.

>     2. Configuring git and hg. I disagree here. I find git anyhow
>        difficult to gasp, but the difference between bare and not bare
>        repos between mirrors and non mirrors, is too complex for me. So
>        the configuration of git seems to be more complicated than with
>        hg. Setting up extensions and configure them does not seem to me
>        a big problem. Let us be honest here, hg-git has *very* little
>        maintainers, authors, contributors, as a matter of fact it is
>        basically Dan, who does this in his free time, and I am very
>        grateful that he does. The topic/named-branch export is still
>        *experimental* and therefore should not be activated per default,
>        without prior testing.!!!!!

Today a streamer said “I want to push, so I need more than just a local
clone”. They are using Git, and Gits limitations caused their idea of
decentralized version tracking to be warped enough that just working
locally seemed far off.

Git limits the imagination of people about decentralized cooperation.

> Till the problem of importing git branches to named branches (or topics)
> is resolved, git branches will be imported as bookmarks to the default
> branch.

I don’t mind importing as bookmarks, so this isn’t really a problem to
me. Bookmarks are usable enough.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1125 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20240719/1c5899de/attachment.asc>