←back to thread

Jujutsu for everyone

(jj-for-everyone.github.io)
434 points Bogdanp | 4 comments | | HN request time: 0s | source
Show context
marcuskaz ◴[] 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 ◴[] 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 #
adastra22 ◴[] No.45084733[source]
I do this every day in git. “git rebase -i [hash]” fyi.
replies(1): >>45084782 #
baq ◴[] No.45084782[source]
you think you do, but you don't; jj edit is much, much better than an edit step in a rebase - it essentially keeps rebasing while you're editing, so you can always see which changes get conflicts, then you are free to resolve them, or not, at your convenience.
replies(3): >>45084799 #>>45086057 #>>45086723 #
adastra22 ◴[] No.45084799[source]
So you get all merge conflicts at once? How is that better?
replies(1): >>45084858 #
baq ◴[] No.45084858[source]
it's exponentially better because you don't need to resolve them until you're ready. conflicts are committed to the local repo like everything else, commits with conflicts are noisily warned about and you can fix them whenever instead of having no other option than immediately.
replies(2): >>45084917 #>>45085054 #
adastra22 ◴[] No.45084917[source]
How does your repo work with conflicts? How does it compile?
replies(2): >>45085447 #>>45086310 #
baq ◴[] No.45085447{3}[source]
The edited commit, assuming it doesn’t have conflicts with predecessors, builds just fine. Successor commits with conflicts that you just introduced predictably don’t - but you aren’t editing them, so it isn’t a problem. In fact, that’s exactly why this feature is so compelling.
replies(1): >>45088030 #
1. adastra22 ◴[] No.45088030{4}[source]
Sorry if I’m being dense, but I still don’t get how this is any different. If I interactive rebase and stop to edit a commit, isn’t that the same thing?
replies(1): >>45089153 #
2. steveklabnik ◴[] No.45089153[source]
You have to finish the rebase before git will let you move in to other work. jj will not. With git you can stop in the middle to make changes, but you must continue until the rebase is done.
replies(1): >>45089925 #
3. adastra22 ◴[] No.45089925[source]
Ok. There are simple workarounds. I git rebase —quit and then make a branch for this saved rebase progress to return to later. I then restart the rebase from the corresponding commit. It would be much nicer if this was all wrapped up a simple command.

There is value here, but I think it is more like “add a new command consisting of 50-100 lines of code” not “write an entirely new VCS.”

replies(1): >>45090285 #
4. steveklabnik ◴[] No.45090285{3}[source]
One little thing here, one little thing there, it all adds up. The jj model is more orthogonal, and so ends up being easier, which also translates to more power.