Defeating Git Rigour Fatigue with Jujutsu • Hacker News Board

Re: Defeating Git Rigour Fatigue with Jujutsu

#161

Post by simonmic » Mon, May 25, 2026, 1:13 PM UTC

krackers wrote: post #132

kccqzy wrote: post #63

Earlier quoted context omitted.

You don’t need easy named branches. Naming branches is a chore: since you already spend time writing commit messages, branch names are just a summarization of your commit messages but with more character restrictions. That’s why I always use jj’s automatic commit identifiers. They are short and I don’t waste brain cycles naming things that are ephemeral. When I push, I let jj automatically creates, updates, and delet…

>You don’t need easy named branches. You can't possibly see a use-case for long-lived branches? Say what you will of git, at least it exposes enough knobs that it can mostly accomodate every workflow (possibly with a heavy porcelain layer to hide the plumbing). JJ seems to swing too far in the other direction, great for a "live on head" mentality but less ideal for other setups. (The fact that all edits are automatic…

You can turn off auto-tracking.

Re: Defeating Git Rigour Fatigue with Jujutsu

#162

Post by muixoozie » Mon, May 25, 2026, 1:29 PM UTC

surajrmal wrote: post #95

hu3 wrote: post #72

Earlier quoted context omitted.

This. I feel jj is some years too late. It tries to solve a human problem in an LLM era. LLMs are destined to overcome humans in code merging and change versioning (already did for me). There's little point to introducing yet another layer of indirection when LLMs just cut to the chase.

A lot of humans don't currently trust agents to touch VCS today. I also find that my agent tends to be much better about dealing with jj than it is with git.

I'm one of those people. I don't really use jj, but want to give it another try. Think I'd feel more comfortable letting ai mess with jj because of its excellent ability to undo/redo (op log).

Re: Defeating Git Rigour Fatigue with Jujutsu

#163

Post by actinium226 » Mon, May 25, 2026, 2:08 PM UTC

I don't get how this is meaningfully different from doing something like:

1. Squash all your commits in this branch to one

2. Move that commit to the working directory with the appropriate git reset command

3. Commit hunks as appropriate.

Re: Defeating Git Rigour Fatigue with Jujutsu

#164

Post by jezzamon » Mon, May 25, 2026, 2:39 PM UTC

gertburger wrote: post #131

I'd like to give jj another go but I found the "all files must be tracked/committed" approach to really break my workflow. I have a lot of temporary uncommitted files, which are not ignored or excluded. Some may eventually be committed but most won't. Being then forced to commit these (but only some due to file size) just gets in the way and impedes things like cross branch debugging A checkout is a working space aft…

If you do want to solve this, here's two thoughts on how you can deal with it. First: don't try to edit jj changes. Always work on a new change and then squash that in to the parent. You think of that top level change as your working space.

From there, the simplest way is to just always use 'jj commit -i' and 'jj squash -i' to create change ids with your work. Then if you want to have your changes move around with you, just rebase your working copy which contains your "uncommitted files" to the new branch.

A different idea is to put those changes in a separate change, and then when you do work, always create your working space change as a merge change like 'jj new . Then you should be able to do 'jj absorb' instead of 'jj squash' to put changes into the right change. Switching to a different branch is 'jj new .

As in typing this, I'm thinking for myself and what I actually do in practice... I find moving / rebasing jj commits very easy (I have a UI tool that literally lets you drag and drop them) so I usually just commit these changes and then drag the commits around so it's not in the chain of when I want to send it out for review

Re: Defeating Git Rigour Fatigue with Jujutsu

#165

Post by jezzamon » Mon, May 25, 2026, 2:46 PM UTC

fragmede wrote: post #26

The elephant in the room is that I haven't had to do something complicated and manual in git by hand in a long while. I'm using AI to generate code, and further, having it commit to git and pushing and pulling and managing branches and merging for me. So for people new to software development, they can also just ask AI to deal with git, which papers over the harder parts of its UX.

You can definitely get stuck in a weird place with git that I haven't run into in the same extent with jj. The ability to undo anything with the one 'jj undo' command is awesome in the agent coding world when it makes a mistake.

Re: Defeating Git Rigour Fatigue with Jujutsu

#166

Post by wocram » Mon, May 25, 2026, 3:08 PM UTC

y1n0 wrote: post #2

I don't get why people like jujutsu. I tried it for a while but I work with a quite a few people in the same repo and I need easy named branches that keep up with commits. For all the many problems in git, branches are dead easy. That was the big innovation over svn at the time. Last time I tried jj, branches were an extremely laborious process to keep up to date. I don't see how people that aren't working alone can…

jujutsu presents the same amount of power with fewer ideas, eg. There is no staging area. It adds new features, like jj undo.

The un-learning curve is steep if you already know git very well.

https://github.com/jj-vcs/jj/discussions/3549 lets you enable automatically advancing bookmarks.

Re: Defeating Git Rigour Fatigue with Jujutsu

#167

Post by wocram » Mon, May 25, 2026, 3:10 PM UTC

sakompella wrote: post #108

y1n0 wrote: post #2

I don't get why people like jujutsu. I tried it for a while but I work with a quite a few people in the same repo and I need easy named branches that keep up with commits. For all the many problems in git, branches are dead easy. That was the big innovation over svn at the time. Last time I tried jj, branches were an extremely laborious process to keep up to date. I don't see how people that aren't working alone can…

i had this exact friction trying to use jj this weekend. can't fathom for the life of me why i have to run another command that updates the branch to the next commit.

https://github.com/jj-vcs/jj/discussions/3549 let's you change this behavior.

I think the idea is that branches/bookmarks aren't as necessary as they are with git.

Re: Defeating Git Rigour Fatigue with Jujutsu

#168

Post by wocram » Mon, May 25, 2026, 3:15 PM UTC

drdrey wrote: post #52

I have finally embraced squashing PRs and realized I wasted my youth trying to write Good Commits.

PRs very frequently contain more than 1 logical change.

Re: Defeating Git Rigour Fatigue with Jujutsu

#169

Post by binarin » Mon, May 25, 2026, 3:23 PM UTC

https://git-scm.com/docs/git-history - git got the remaining piece of the puzzle to make massaging history relatively easy. "git history split", interactive rebase and fixup/auto squash allow you to do anything in a more systematic way than resetting/selectively staging/committing again and again.

Re: Defeating Git Rigour Fatigue with Jujutsu

#170

Post by riwsky » Mon, May 25, 2026, 3:34 PM UTC

gmueckl wrote: post #115

nextaccountic wrote: post #55

> Latter commits overwrite work that was done in earlier commits and the story breaks. > Some people prefer this, as it helps git bisect work better. Debuggability versus reviewer convenience is the tradeoff, I guess. Ideally we would have a VCS that made ergonomic to store both history-as-it-happened for some purposes, and the cleaned up, squashed and rebased history for other purposes, ensuring they match

I think that version control has reached a point where the next major evolutionary steps will be based on making history totally shared and immutable with history edits themselves being non-destructive versioned operations that can be browsed as higher order history.

That’s, uh, exactly how jj works!