←back to thread

Jujutsu for everyone

(jj-for-everyone.github.io)
434 points Bogdanp | 3 comments | 31 Aug 25 15:31 UTC | HN request time: 0.004s | source
Show context
collinmcnulty ◴[31 Aug 25 17:12 UTC] No.45084889[source]▶
I’ll hop on the train and say that I’ve been using jj recently as well, and it’s given me that feeling of safety and freedom I got when I first started using version control 10 years ago. That sense that “well this is a crazy idea but I’ll just commit now and try it, I can always roll back”.
replies(1): >>45089237 #
KingMob ◴[01 Sep 25 03:42 UTC] No.45089237[source]▶
It's still insane to me that universal `undo` is not a basic git command.
replies(1): >>45089983 #
Cthulhu_ ◴[01 Sep 25 06:20 UTC] No.45089983[source]▶
That's because there is none, because you're dealing with 4 locations (local, staging, local branch, remote branch); which one do you want to undo?
replies(1): >>45091054 #
1. KingMob ◴[01 Sep 25 09:28 UTC] No.45091054{3}[source]▶
Any of them. All of them. (Maybe not remote changes, but that's way less safe to attempt, even if possible.)

Which is what `jj undo` does, and why I brought it up.

I'm well aware git doesn't have a unified concept of undoing, but I'm equally aware that it's possible. (Even before jj, GitUp and git-branchless offered universal undo.)

replies(1): >>45093852 #
2. SAI_Peregrinus ◴[01 Sep 25 16:03 UTC] No.45093852[source]▶
Not to mention Git has a reflog, so `undo` could just always revert the last operation in the reflog. Or the last `n` operations if specified. So there already is a universal list of what operations were performed, and thus what operations for `undo` to work on.
replies(1): >>45120335 #
3. phatskat ◴[03 Sep 25 20:56 UTC] No.45120335[source]▶
Git always baffled me with revert - I learned early on that if I wanted to “undo” something, the best bet was to either branch from a commit before the thing I want undone, and maybe rebase/cherry pick later commits, or just start over.

This seems like the ideal case for revert, but the way that it alters the history stings - the fact that reverting a commit essentially means that said commit can’t show up later as a change is frustrating - also I’m sure it’s a case of user error, but…”merge branch, realize there’s a big oops in there, revert, fix the oops on the branch” feels like it shouldn’t result in a state where git doesn’t accept the branch as mergable.