I am slowly inching towards trying out jj. I think the main issue will be if I find some issue in the git compatibility aspect. I do two kinds of work:
1. Work on smaller projects with simple histories. Git is perfectly satisfactory.
2. Work on huge projects with very complex git histories and weird legacy workflows (primarily Linux kernel).
jj is only interesting for part 2, but then it's only useful if it's easy to bridge into the Git world that everyone else uses.
But this workflow is exactly the kind of thing that seems handy. There's so much stuff that Git can totally _do_ but could just do a lot _better_.
I converted 6mo ago after finally pulling together the motivation to give it a shot. My biggest hesitation was in how long I expected to struggle with it before feeling comfortable, followed closely by skepticism about how good the compatibility story actually is.
Both, it turns out, were non issues. It took all of a day to feel perfectly comfortable using it. I spent the rest of the week gradually plugging most of the remaining holes in my workflow. And git compatibility is as advertised. A coworker switched shortly after I did and zero people have noticed or cared.
Though at this point I don’t even bother colocating the .git repo alongside .jj. Meaning I haven’t found a need to fall back to git commands in maybe four or five months.
> Though at this point I don’t even bother colocating the .git repo alongside .jj. Meaning I haven’t found a need to fall back to git commands in maybe four or five months.
That interests me -- is there a native jj protocol for push/fetch? Even if just ssh? Or do you just work in local repos?
Backends can do whatever. The git backend knows how to push to git remotes. If you used a different backend, it would know what those backends expect. There aren’t any of these publicly, but Google has one to work with piper.
Google's internal git support for the Google3 monorepo was deprecated/is unsupported in favor of fig, the mercurial/hg based client for Google3.
Microsoft has a custom git client internally which includes a filesystem shim (think: the Windows equivalent of FUSE) since stat-ing monorepo amounts of files doesn't work. Also GitHub's running custom git servers, though their custom database backend is behind a compatibility layer.
Finally, sapling, Meta's git replacement which maintains supports for git servers also supports sapling servers (which was not released). Unsure whether to count that as a git backend though.
How's the tool compatibility when using gg tho? My repo work tends to be split between git and magit, and while I would very much welcome the ability to get rid of git for a better experience, doing so at the cost of magit is an extremely steep hurdle.
I actually find jj great for (1). The project I reference working on in this post is in exactly that bucket, and the kinds of things I do with it are not “complicated” but jj is still much, much better than working with Git—not least for the kind of workflow I showed in this post!
1. Work on smaller projects with simple histories. Git is perfectly satisfactory.
2. Work on huge projects with very complex git histories and weird legacy workflows (primarily Linux kernel).
jj is only interesting for part 2, but then it's only useful if it's easy to bridge into the Git world that everyone else uses.
But this workflow is exactly the kind of thing that seems handy. There's so much stuff that Git can totally _do_ but could just do a lot _better_.