>>> "PA" == PIERRE AUGIER <pierre.aug...@univ-grenoble-alpes.fr> writes:
> 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.
A couple of remarks, but mainly concerning the interaction with git, and
mercurial using hg-git either with dan's branch or with Manuel's (but
Manuel's version can't be used at the moment in more modern hg versions
, although I feel a bit tempted to give it a try).
> Using /usr/bin/python3 -m pip install (--user) or --break-system-packages are
> really bad practice.
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.
> 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.
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.!!!!!
> 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).
> 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.
3. The hg-git problem. For me one of the main problems of git is
that you never know (with absolute certainty) to which branch a
commit belongs. Yes there is git name-rev, this is a clever
algorithm will calculates which commit might belong to which
branch and shows it in the graph. The problem is: it is not
failsave, you can easily come up with a git repo (containing say
5 commits and name-rev associate the commits incorrectly. Such an
example was provided to me by Arne Babenhauserheide, who I think
is also forced to use git.
This fact seems to me one of the reasons why it is so difficult to
import git branches as named hg branches (or topics). There is a
conversion tool, written by a git hacker, Felipe Contreras, which
converts git branches into named hg branches, but it uses
name-rev, with the problems mentioned.
To sum up, the hg-git export-import problem is a *very* difficult one,
hg-git as very few contributors, and very few authors even tried to deal
with that problem.
I wish I knew enough python to really contribute. I might try to export
Manuel's 2 changesets to python 3.X (not sure that this would be a very
good idea), but I prefer to run more tests on the current experimental
implementation by Dan.
The advantage of using topics instead of named branches is the
following:
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. Using topics then is much more flexible than named branches, because
moving these imported changesets to other named branches in hg will
cause a lot of problems when exporting them again. I did some
experiments on this and found it not usable.
So for me, who does not understand really git (for example the
difference between local branches and remote branches and remote
tracking), who does not like the fact that I don't know in which branch
a change set is, the current situation is not as negative as you see it.
I feel grateful for all the efforts the hg hackers did.
Regards
Uwe
--
I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel
I strongly condemn Putin's war of aggression against Ukraine.
I support to deliver weapons to Ukraine's military.
I support the EU and NATO membership of Ukraine.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Mercurial mailing list Mercurial@lists.mercurial-scm.org https://lists.mercurial-scm.org/mailman/listinfo/mercurial
