[itchynosedev]

I really loved jujutsu for the few weeks that I used it. However, I did find all my tools that rely on Git (eg Gitlab CLI that can open merge request from the current branch) breaking because JJ operations result in detached head in Git.

In addition, mixing Git and JJ will result in your repos becoming really slow when you do need to run some Git operation.

[stavros]

Hm, I can't speak to the tools, I imagine you're right. I haven't found any slowness, though. Why would jj slow git down?

[itchynosedev]

I noticed some of my hybrid repositories were slow on regular git commands (eg log) and running garbage collection manual resolved it. Perhaps, jj created a lot of unreachable objects?

[1718627440]

JJ invites rebase heavy workflows and since it uses git, commits are still immutable, so it needs to create new commits. So this sounds quite expected.

[1718627440]

I also use them, because I don't know a better alternative. I want it the subproject's version to be defined in a parent's commit and also modify the subproject. Changes to the subproject should stay in the commit history of the subproject Is there a better way?

[ljm]

One of the bigger selling points of JJ just wouldn't work so well without larger team buy in for me: the ability to push stacked PRs.

I like the idea of it, but there's so much inertia around typical git workflows that revolve around the GH pull request model (with the only difference being the use of trunk based dev or some git-flow like branching strategy) that it'd be hard to change without a lot of buy in.

I still think back to Phabricator and its approach to code review, noting that it sadly never got wider traction despite having notable benefits over a completely entrenched status quo.