Git compatibility is a great way around this problem. I have been enjoying Jujutsu lately.
Git compatibility is a great way around this problem. I have been enjoying Jujutsu lately.
So long as you require git compatibility, you're kinda stuck with git's view of what history looks like. Which is rather the point.
jj is not patch based, like pijul, but snapshots, like git.
A sibling commentor points out the change id stored by jj: it is true that at the moment, this isn't really exportable to git in a native way. However, there is a path forward here, and it may come to pass. Until then, systems like Gerrit or Phabricator work better with jj than systems like GitHub.
However, all is not lost there either: tooling like spr[1] allows you to map between the two universes.
At my job, at least one person was using jj for six months at work without any of the rest of us being the wiser. Some of the rest of us are trying it out. A really nice thing about jj is that you can use it without anyone else needing to, thanks to the git interop.
(I've worked with the main author of Jujutsu before. Also, having worked on Mercurial for many years, I have my biases about how source control should work. Jujutsu's workflow is very similar to Mercurial's, with some rather stunning improvements on it.)
Adjacent, I heard folks praising Forgejo for its Actions & Microsoft GitHub compatibility, but that means you are still left with the same YAML spaghetti and its other limitations. What would have been nice is something better for CI--something that prompts the project to want to switch to get a better experience. As such, while I agree with the moral reasons to switch to non-proprietary software, the reason for switching is philosophical, not philosophical + technical. I feel being a wrapper around Git or Git compatibility will likely fall in this category rather than being more compelling.