alt Hacker NewsDefeating Git Rigour Fatigue with Jujutsu
Comments
> `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.
Jujutsu's approach to treating the working copy as a commit solves so many common friction points with Git rebase workflows. Great to see it gaining more adoption.
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 after all, why can't it be (temporarily) dirty whilst you work?
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.
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.
I have finally embraced squashing PRs and realized I wasted my youth trying to write Good Commits.
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.
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.
> This allows reviewers to step through your pull request in small bites, with each set of changes scoped to a single aspect of the feature.
Is that a frequent way of reviewing? On GitHub you get shown all changes together in the review tab. You can select individual commits for closer inspection, but where is the benefit?
> 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
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 don’t understand. Are there people that try to use git without ever invoking “git rebase -i” ?
New tools are cool, but from what I have seen jj is literally just git with aliases
git let me make changes to local files without fear, since version control let me undo those changes easily.
jj let me make changes to my git commits without fear, since version control of the git state itself let me undo those changes easily, too.
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!
Agentic development transforms the scope of work. Once a session is committed to having one topic from the get-go — one move, one service, one abstraction — the diff generated from such a session is atomic by construction. Committing happens at the session level, and the commitment discipline problem solved by Jujutsu does not come into play.
It is also true in reverse. Scopes set too broadly ("dark mode implementation," "auth flow fixes") lead to un-readable diffs no matter what tool you use for version control. Un-readable diff does not stem from commitment discipline; it is a scope problem.
That said, this fact does not diminish the usefulness of Jujutsu. There are valid use cases for the rebase and stacking operations. However, the discussion about commit granularity takes on a whole new context once the constraint of having readable commits is established at the scope setting stage.
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.
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'
This is roughly how I’ve found myself using jj naturally. I find it hard to “tell the story” of a change ahead of time, because the design often only becomes clear after some exploration. It’s much easier to land at an implementation I’m happy with, then work backwards and shape the commits into the story I wish I’d taken.
So I'd have an immediate problem with the target sequence of commits here. The thing about just getting a "define types" commit is that it shows me nothing about why those types were chosen. I need to flit backwards and forwards in history to see how they hook into the later code. I lose the history of "this type was enough to get us to point A, we needed this other thing to get to point B". But flitting back and forth is exactly what we're trying to avoid here. It feels like we're trying to optimise to One True Clean History, when that can't possibly exist because no two people's idea of "clean" actually matches.
Just give me the PR, don't sweat the individual patches. But maybe also work on not committing your first idea as finished work.
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.
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.
> 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.
`git rebase -i` and `fixup`
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.
> 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.
So: Squash everything together then pick each component out by squash -i to an empty commit.
Seems straightforward, wouldn’t call it special
[flagged]
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 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.
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.