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.da...@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.dente...@gmail.com> > <sandro.dente...@gmail.com> > À: "Uwe Brauer" <o...@mat.ucm.es> <o...@mat.ucm.es>, "mercurial" > <mercur...@mercurial-scm.org> <mercur...@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@lists.mercurial-scm.org <mercurial@lists.mercurial-scm.org> > | mercurial@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@lists.mercurial-scm.org > https://lists.mercurial-scm.org/mailman/listinfo/mercurial >
_______________________________________________ Mercurial mailing list Mercurial@lists.mercurial-scm.org https://lists.mercurial-scm.org/mailman/listinfo/mercurial
