←back to thread

Jujutsu for everyone

(jj-for-everyone.github.io)
434 points Bogdanp | 2 comments | 31 Aug 25 15:31 UTC | HN request time: 0s | source
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 #
ileonichwiesz ◴[31 Aug 25 17:37 UTC] No.45085106[source]▶
Okay, sure, but if I realize I should’ve done something differently in commit 1, why wouldn’t I just make a new commit with the fix?
replies(3): >>45085225 #>>45085789 #>>45087384 #
tomstuart ◴[31 Aug 25 17:49 UTC] No.45085225[source]▶
Do you want another person (or yourself in the future) to be able to read your commits, in order, to get a clear account of what changed & why? If so, you should fix up those commits to address mistakes. If not, it doesn’t matter.
replies(3): >>45085388 #>>45085450 #>>45090987 #
1. thecupisblue ◴[01 Sep 25 09:17 UTC] No.45090987{3}[source]▶
Yes, but in that case, I want the fix of the original mistake to be done in a new commit.

Why?

Example #1: - I am working on implementing API calls in the client, made 3 commits and opened a PR - In the meantime, the BE team decides they screwed up and need to update the spec

If I now go and fix it in the commit #1, I lose data. I both lose the version where the API call is in its original state, and I lose the data on what really happened, pretending everything is okay.

Example #2: - I am writing a JVM implementation for our smart-lens - In commit #2 I wrongly implement something, let's say garbage collection, and I release variables after they have 2 references due to a bug. - I am now 6 commits ahead and realise "oh shit wait I have a bug"

If I edit it inline in commit #2, I lose all the knowledge of what the bug was, what the fix is, what even happened or that there was a bug.

tldr: just do an interactive rebase

replies(1): >>45112884 #
2. phatskat ◴[03 Sep 25 06:41 UTC] No.45112884[source]▶
From what I understand of how jj works, and I’m happy to be corrected because I’m still learning it, is that going back and editing those commits doesn’t change actual original “change” - that is, jj tracks a change ID to everything, and those original commits (once pushed) are immutable. So in theory, with jj, you should be able to see the original commit and the change to fix it, and you can still couple them into a single commit without losing that change history.