| At work I’ve been using jj for the internal Standard Chartered monorepo (6.5 MLOC). I didn’t ask anyone, just installed and started using it. Git compatibility is a killer feature. (if anyone from SC is reading this -- search our wiki for "Jujutsu" and come say hi!) Pretty much a strictly better experience than git so far — I’m not going back. `jj undo` is something that I expect in every program now and get vaguely annoyed it's not there. Not having index/staging is great. Checking out another branch, switching to work on another thing, fixing a typo in an unrelated module, etc are all frictionless. "I'll insert a new commit five-commits-ago, do the refactoring there, and resolve conflicts" turns out to be much nicer than "I'll do the refactoring here and carefully stage it hunk-by-hunk". (I get distracted a lot -- maybe if you aren't tempted by shiny refactorings, this isn't a big deal for you.) The merge story is also great. I have a commit with multiple parents. I can add more parents to it, change parents, rebase it somewhere, move it around. I have no idea how "rebasing a merge" works in git, but I'm afraid to try. In jj I don't care. There are a few issues with jj that happen to not be a big deal for me, but I can imagine they could be a dealbreaker for someone else: - No submodules support (yet) - No LFS support (yet?) - Doesn't track renames (yet?) - When you do `git pull` with rebase, git skips duplicate commits -- this is great if something got rebased/amended on the remote. I was always suspicious that `git pull` just works even if I rebased the branch remotely, and now I know why it works. jj doesn't handle this yet. Not a big deal unless two people collaborate on a branch and want to do it the jj-way with rebases of everything. |
I did some profiling & it looks like the issue lies with `libgit2`, but I haven’t been able to replicate the issue outside of that work codebase[0].
[0]: https://github.com/martinvonz/jj/issues/1841#issuecomment-23...