Defeating Git Rigour Fatigue with Jujutsu

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 work with that. I have numerous branches in flight at any given time, and my colleagues do as well. The idea of manually keeping them pointed at the right commit is just nuts.

Maybe they've fixed that astonishing choice since then, and I'd give things another go if they did. But branches and worktrees are how I operate.

Regarding the article, I have no idea what is going on as I'm red-green color deficient.

> `absorb` assigns the changes based on whichever previous commit most recently touched those files, which sometimes doesn't actually correspond to which commit should own these particular changes.

I’m pretty sure `jj absorb` (and its predecessors, `git-absorb` [0] and `hg absorb`) are smarter than this, instead looking at the actual diffs.

[0]: https://github.com/tummychow/git-absorb

This seems like a lot more effort than the (to me) more natural jj workflow of maintaining the idealized series of commits plus a working commit on top. As you make tweaks and fixes you just squash the relevant parts into the already-clean history.

Basically, if you don’t get into that sort of situation with commits containing parts they shouldn’t in the first place, you don’t need to do any extra work to clean them up. The tip of your branch should be the only “messy” part.

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

As a git rebase enjoyer, I've completely switched over to jujutsu. The whole experience is more ergonomic in my opinion, and the default workflow which I use (using `jj new` to create a new change that clearly delineates work on a different "thing" before I start working on it) fits my mental model much better than the traditional write-then-commit workflow we all grew up with.

> 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 like how jj allows me to essentially use the same workflow in my personal projects (jj on git) as with my work stuff (jj on piper). That alone is really neat!

I don’t understand. Are there people that try to use git without ever invoking “git rebase -i” ?

This remind me of [jj megamerge](https://isaaccorbrey.com/notes/jujutsu-megamerges-for-fun-an...). jj allows concentrating on developing while leaving things for vcs alone, as well as solving vcs things (conflicts) at very beginning (megamerge). Really good.

> A downside to this technique is that there's no guarantee that every commit will compile, which might be a dealbreaker.

To some of us, that's an essential structural criterion. Passing unit-level self-tests may be as well.

Or let an agent deal with any git nonsense. Yes I’m already aware some smart alec will lie about the time an agent totally deleted their entire repo and branch.

I tend to just commit whenever I see fit, then at the end I do a `git reset —soft` and write the history that makes sense before pushing.

With jj I mostly just `jj split -B @`. Nice interactive ui for picking the changes I want into a commit. So many times better than 'git add -p'

The only thing that stops me from switching to jujutsu is that lazygit already paves through all these paper cuts pretty well, and I'd miss their custom patches feature.

I see there's a similar project for JJ, but it doesn't seem nearly as polished https://github.com/Cretezy/lazyjj

I'm not an expert in Magit by any means, but I bet there's a way to accomplish this in only a few keystrokes.

So... git rebase -i?

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.

So: Squash everything together then pick each component out by squash -i to an empty commit.

Seems straightforward, wouldn’t call it special

I have been walking some newer programmers through Git recently, so this topic is fresh on my mind. The commands in the blog post do not look friendlier or even different.

> For large features, I find this workflow far easier than having to maintain strict git rigour for the lifecycle of the feature's development.

I don't know about all that. All sorts of ex-post-facto automated cut-up-and-splice commits sounds to me like a recipe for an every larger mess. I say maintain git rigor, always. Now, you could say "You only say that because you know git rather than jujutsu" or "if you use git absorb more you'll get it", and theoretically you might be right, but... meh, I kind of doubt it.

[flagged]