I still default to Mercurial for new projects, but I’ve been using Jujutsu for contributing to git projects. It’s absolutely a WIP, but it’s actively progressing and, whereas I found it unusable several months ago, I’m currently able to successfully use it to contribute to upstream projects without having to touch git much.
Conceptually, the project is still working through some best workflow design decisions; there’s a drift toward a Mercurial bookmarks style which I fully support, although there’s a clear faction that argues bookmark/branchless development is fantastic under jj, with bookmarks being last-minute pre-push things.
I have been surprisingly impressed by merging and conflict resolution under jj; it’s one of two things that I believe give the project enough legs to maybe someday replace hg as my default for new projects. While I don’t understand it well enough to do it justice, multi-branch merges are less like merging and more like rebasing onto multiple targets: you create a new commit and give it multiple parents. Like, seriously, multiple. At one point in a project to which I contribute, I had 6 PRs lined up waiting for merging by the project owner. Under jj, my personal dev branch, I created a new change off main@upstream and added 6 of my branches as parents of the change. Believe me, the log history graph looks weird on something like that. The change has conflicts, obviously, but in jj conflicts are first-class history events and are recorded in the log. Resolve the conflicts, and commit those changes. At any point in the future, you can jump back to that conflict commit and redo the resolution. It’s a lot like FP monads: at first maybe frustrating that you have to deal with them, them they start to make sense, and you end up thinking all other languages are idiots for not using them.
The second killer feature, over hg for me, is that there’s currently one backend storage for it, and that’s git. It means being able to work with far more projects hosted on git-only hubs without having to deal with what, IMHO, is the clusterfuck that is git. But the developers are very careful about preventing git-isms creep into the UI or design; there’s a currently hypothetical future where users can chose git, Mercurial, or even darcs as a storage backend. This comes up a lot in any discussion about branches and bookmarks.
I don’t think it’s currently ready for primetime; there’s still a lot of decisions needing to be made, and regular changes to “best practices” workflow. And warts: e.g. should bookmarks float like in hg, or not? Currently, it’s an experimental feature. And I am dumbfounded by the decision to auto-track any new file that appears in the working directory; I can’t imagine who finds this useful, since stopping it involves either disabling it entirely, which makes tracking new files awkward; or constantly adding new files to .gitignore and running a command to tell jj to stop tracking the file … it’s such a perfect recipe for accidentally exposing credentials that I don’t know how the feature is internally justified.
Mercurial has its own warts, which can be worked around with extensions but which shouldn’t be warts at all: no shallow clone support; the project keeps inventing new workflow modalities and at any point it’s not clear which workflow is the recommended one (bookmarks? evolve’s topics?). And I frequently have trouble that fundamentally traces back to Mercurial being a Python ecosystem. hg+git is constantly breaking, extensions fall behind and become incompatible with whichever Python version hg requires… it’s the usual interpreted language dependency hell I complain about, but if I step away from development for a couple of months, and there are any software updates during that time, that the first time I run hg in a project I’ve had for more than a few years I’m first going to have to spend an hour fixing extensions, or upgrading the repo, or some crap. One feature hg used to have over git was stability and reliability; it no longer does, and much of this is because Python.
Regardless, there’s a lot more to like about where jj is going and how it’s getting there, and I’m pretty exited about it. Despite currently fighting with jj about pushing changes to github branches (as in, it won’t, and I don’t know how to fix it), I get around this by just using git push (and it’s awful syntax) directly. Other than that, I haven’t had to use git in a couple months despite doing some heavy contributing to a github project, and for that, I’m grateful.
I still default to Mercurial for new projects, but I’ve been using Jujutsu for contributing to git projects. It’s absolutely a WIP, but it’s actively progressing and, whereas I found it unusable several months ago, I’m currently able to successfully use it to contribute to upstream projects without having to touch git much.
Conceptually, the project is still working through some best workflow design decisions; there’s a drift toward a Mercurial bookmarks style which I fully support, although there’s a clear faction that argues bookmark/branchless development is fantastic under jj, with bookmarks being last-minute pre-push things.
I have been surprisingly impressed by merging and conflict resolution under jj; it’s one of two things that I believe give the project enough legs to maybe someday replace hg as my default for new projects. While I don’t understand it well enough to do it justice, multi-branch merges are less like merging and more like rebasing onto multiple targets: you create a new commit and give it multiple parents. Like, seriously, multiple. At one point in a project to which I contribute, I had 6 PRs lined up waiting for merging by the project owner. Under jj, my personal dev branch, I created a new change off main@upstream and added 6 of my branches as parents of the change. Believe me, the log history graph looks weird on something like that. The change has conflicts, obviously, but in jj conflicts are first-class history events and are recorded in the log. Resolve the conflicts, and commit those changes. At any point in the future, you can jump back to that conflict commit and redo the resolution. It’s a lot like FP monads: at first maybe frustrating that you have to deal with them, them they start to make sense, and you end up thinking all other languages are idiots for not using them.
The second killer feature, over hg for me, is that there’s currently one backend storage for it, and that’s git. It means being able to work with far more projects hosted on git-only hubs without having to deal with what, IMHO, is the clusterfuck that is git. But the developers are very careful about preventing git-isms creep into the UI or design; there’s a currently hypothetical future where users can chose git, Mercurial, or even darcs as a storage backend. This comes up a lot in any discussion about branches and bookmarks.
I don’t think it’s currently ready for primetime; there’s still a lot of decisions needing to be made, and regular changes to “best practices” workflow. And warts: e.g. should bookmarks float like in hg, or not? Currently, it’s an experimental feature. And I am dumbfounded by the decision to auto-track any new file that appears in the working directory; I can’t imagine who finds this useful, since stopping it involves either disabling it entirely, which makes tracking new files awkward; or constantly adding new files to .gitignore and running a command to tell jj to stop tracking the file … it’s such a perfect recipe for accidentally exposing credentials that I don’t know how the feature is internally justified.
Mercurial has its own warts, which can be worked around with extensions but which shouldn’t be warts at all: no shallow clone support; the project keeps inventing new workflow modalities and at any point it’s not clear which workflow is the recommended one (bookmarks? evolve’s topics?). And I frequently have trouble that fundamentally traces back to Mercurial being a Python ecosystem. hg+git is constantly breaking, extensions fall behind and become incompatible with whichever Python version hg requires… it’s the usual interpreted language dependency hell I complain about, but if I step away from development for a couple of months, and there are any software updates during that time, that the first time I run hg in a project I’ve had for more than a few years I’m first going to have to spend an hour fixing extensions, or upgrading the repo, or some crap. One feature hg used to have over git was stability and reliability; it no longer does, and much of this is because Python.
Regardless, there’s a lot more to like about where jj is going and how it’s getting there, and I’m pretty exited about it. Despite currently fighting with jj about pushing changes to github branches (as in, it won’t, and I don’t know how to fix it), I get around this by just using
git push(and it’s awful syntax) directly. Other than that, I haven’t had to use git in a couple months despite doing some heavy contributing to a github project, and for that, I’m grateful.