←back to thread

Jujutsu for everyone

(jj-for-everyone.github.io)
434 points Bogdanp | 6 comments | | HN request time: 1.351s | source | bottom
1. collinmcnulty ◴[] 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 #
2. KingMob ◴[] No.45089237[source]
It's still insane to me that universal `undo` is not a basic git command.
replies(1): >>45089983 #
3. Cthulhu_ ◴[] 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 #
4. KingMob ◴[] 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 #
5. SAI_Peregrinus ◴[] No.45093852{4}[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 #
6. phatskat ◴[] No.45120335{5}[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.