We had a great discussion mostly about Jujutsu, and the philosophy of Git commit organization, giraffe violence, etc.
Here's a list of the auxiliary tools we looked at, which will require little extra config to set up with jj. Most of these can also be used with plain git.
-
Immutable changes: The log shows a blue diamond instead of an empty circle node for tree segments that are immutable, which protects shared history (usually remote-only branches) from all the methods you would
normally use modify commits in jj.
-
Stacked pull requests: I don't wait for pull requests to be merged before I start working on more on top of their work. It's easy to rebase the stacked work for another PR when the first one gets merged. This
does risk my time being spent on more code that gets thrown away if a PR is rejected, but writing and learning from code is not considered wasted time by me.
-
Optimizing the graph for review: We discussed the balance of whether the entire history should be preserved in Git, and I prefer to keep a balance of preserving history and splitting/squashing commits into more
functional steps that can be easily reviewed by others. Jujutsu locally preserves the evolution of each change across the commits behind it, and has a rich undo system, so I don't lose my raw history that I might need to recover in anger. Still, I can intentionally
organize commits with a balance of reviewability, preserving the intentions behind changes, demonstrating evolution of a large change, etc.
-
Megamerges: If I have any number of open and/or stacked pull requests that I want to test all together, I can set them as parents to a single merge commit. This is easy and conflict-free when they deal with different
functional areas in a codebase, but finding 3+ sided merge conflicts can be a signal that I need to reconsider how I've organized my changes.
-
Absorb: For each hunk in a change, this jj command will automatically squash them into adjacent/overlapping hunks further up the tree. This allows you to hack away at the tip of the tree, then instead of choosing
where to squash disparate edits, absorb will squash them into any non-immutable commit for you. This works for merged branches as well, so I can e.g. absorb doc changes into my docs PR branch, and absorb the feature changes into the feature PR branch.