←back to thread

Jujutsu for everyone

(jj-for-everyone.github.io)
434 points Bogdanp | 8 comments | 31 Aug 25 15:31 UTC | HN request time: 0.002s | source | bottom
Show context
marcuskaz ◴[31 Aug 25 16:14 UTC] No.45084298[source]▶
> Jujutsu is more powerful than Git. Despite the fact that it's easier to learn and more intuitive, it actually has loads of awesome capabilities for power users that completely leave Git in the dust.

Like? This isn't explained, I'm curious on why I would want to use it, but this is just an empty platitude, doesn't really give me a reason to try.

replies(7): >>45084316 #>>45084327 #>>45084439 #>>45084678 #>>45088571 #>>45092597 #>>45093098 #
pkulak ◴[31 Aug 25 16:51 UTC] No.45084678[source]▶
Say you start on Main, then make a new branch that you intend to be a PR someday. You make commit 1. Then another. Maybe 6 more. Now you realize that something in commit 1 should have been done differently. So, you "edit" commit 1. All the other commits automatically rebase on top and when you go back to your last commit, it's there. Same with _after_ you PR and someone notices something in commit 3. Edit it, push, and it's fixed.

You can do all that in Git, but I sure as hell never did; and my co-workers really appreciate PRs that are broken into lots of little commits that can be easily looked over, one by one.

replies(4): >>45084727 #>>45084733 #>>45084935 #>>45085106 #
1. lrobinovitch ◴[31 Aug 25 16:56 UTC] No.45084727[source]▶
You have to force push each time you do this, right? How do your coworkers find the incremental change you made to commit 1 after you force push it, and how do you deal with collaborative branches effectively this way? And if I don't want to work this way and force push, are there other benefits of jj?
replies(2): >>45084790 #>>45085517 #
2. baq ◴[31 Aug 25 17:02 UTC] No.45084790[source]▶
the heuristic is 'if you know about rerere and especially if you use it, you should try jj'. if you never force push, you might not see value in jj. (I basically always force push.)
replies(1): >>45084944 #
3. lrobinovitch ◴[31 Aug 25 17:18 UTC] No.45084944[source]▶
That makes sense, good to know, thanks.

> I basically always force push

How do your colleagues deal with this, or is this mostly on experimental branches or individual projects?

replies(4): >>45085108 #>>45085122 #>>45085521 #>>45086437 #
4. whateveracct ◴[31 Aug 25 17:37 UTC] No.45085108{3}[source]▶
People barely ever work off my branches.
5. smw ◴[31 Aug 25 17:39 UTC] No.45085122{3}[source]▶
It's generally fine if you force push a branch that you're the only one working on. In many projects, there's an expectation that the 'PR Branch' you create in order to make a github pull request is owned by you, and can be rebased/edited/force-pushed at will. It's very common to do things like `git commit --amend --no-edit` to fix a typo or lint issue and then force push to update the last commit.

This has it's problems, and there's a reason things like Geritt are popular in some more sophisticated shops, as they make it much easier to review changes to PRs in response to reviews, as an example.

6. Disposal8433 ◴[31 Aug 25 18:17 UTC] No.45085517[source]▶
IIRC it's push force with lease, ie non destructive push force. No one will be bothered or notice what you did.

And if you have conflicts, it's really easy to rebase and fix any issue.

7. baq ◴[31 Aug 25 18:18 UTC] No.45085521{3}[source]▶
The PRs are either small enough that it isn’t a problem or large enough that it isn’t a problem… the odd in-between PR experience sucks and it’s one of the cases when I sometimes add more commits instead of force pushing.

+1 to sibling gerrit recommendation; I used to use it a decade ago and it was better then than GitHub PRs today.

8. andrewaylett ◴[31 Aug 25 19:48 UTC] No.45086437{3}[source]▶
JJ has the concept of "immutable changesets" -- if it sees a commit is referenced from a branch that it's not tracking, it assumes it ought not rebase that commit. Changesets on branches that look like the main branch are immutable too. And you can edit the revset that JJ considers immutable if you need it to be different from the default.

The net effect is that I can change "my" branches as I wish, but I can't change stuff that's been merged or other folks' branches unless I disable the safety features (either using `--ignore-immutable` or tracking the branch).

JJ also makes it really easy to push a single changeset as a branch, which means as you evolve that single commit you can keep the remote updated with your current work really easily. And it's got a specific `jj evolog` command to see how a specific changeset has evolved over time.