History is immutable ONCE it’s merged. Prior to that, it’s malleable. We rewrite our branch history fairly often. I’ll take a big PR that’s ready, and rewrite the history in a way that tells clear story. This lets me stack PRs so it’s easier for coworkers to digest the work. It hides the messy reality of how it was constructed. It lets the development process follow evolutionary design, without review being miserable at the end of the day. This also makes git-blame 6 months later way more useful, as the commits end up much tidier with better messages and clearer story being told.
I'm missing a good way to turn on/off plugins and settings depending on the directory. Eg turning off rust-analyzer on some projects, or using pyright instead of mypy as the LSP.
Same experience. At first I really didn’t get it and now I could never go back. The ease of rebasing, renaming, reordering, splitting, etc. Has drastically changed the way I work. My PRs are undoubtably much better now, and I am never afraid of messing up thanks to jj undo and the op log in general
Do you have a public example of an open source project that you are using that showcases those features?
In your opinion, is jj losing steam? How do you feel about it requiring a CLA to contribute to, which would enable the developers to go closed-source and keep all the contributions of the community? Are you afraid of vendor lock-in?
> a public example of an open source project that you are using that showcases those features?
IMO that's almost fundamentally impossible. The whole point is that it makes maintaining a "clean" linear commit history easier than git, so by the time you push anything the observable differences are already gone. At best you just see a repo without any WIP-style commits, which can be done using more effort and git alone.
reply