scottgg

You can do it to any change in the repo and everything gets automatically rebased downstream of it - so if you three nicely structured changes you can go change the first one if you need and it just works.

I’m selling it short a bit - it does a lot more! There’s a great Steve Klabnik tutorial [1]. To me the main thing is it makes it very easy to think and work in terms of logical changes.

[1] https://steveklabnik.github.io/jujutsu-tutorial/

I reckon that nice commits breaking up a big PR that can be merged straight to main is the best outcome.

But - I also think that always squashing is a natural reaction to "twiddling with the past" being difficult (but possible!) with git - e.g., you start with good intentions, you have your nice commit messages, but inevitably you need to go back and make some changes to changes and the "chore: unfuck it for real this time" style "fixup" commits start creeping in and you throw your hands in the air in despair rather than dare to cross `git rebase` once more.

Since moving to jj[1] as a git-compatible alternative, I’ve found it so easy to make clean commits I do it by default for everything - usually 1/ refactor 2/impl, 3/ docs. Because you can always just “jj new” on top of an existing change then squash it down and get automatic rebase past that point it’s quick to keep things organised and makes review life suck less.

[1] https://github.com/jj-vcs/jj

you get _a_ strong credential, or you get _strong credentials_ , probably

There's a lot going on in there!

I recently did the same thing with AWS, using the CDK to make it easy to add and remove regions [1]. I use it to hop my traffic around as required.

[1] https://blog.scottgerring.com/automating-tailscale-exit-node...

There’s also DN42 [1] if you want to mess around with a bigish BGP network for free

1. https://dn42.eu/Home