I didn’t have enough money in my account for groceries at a grocery store. I had to walk out without it. While I was trying to figure out what I was going to do, a lady came up and handed me my groceries. She just said don’t worry about it and walked away. She didn’t make it weird or make me feel bad at all. So thankful for that random lady. I doubt she has any idea how much it’s meant to me over the years thinking about it.

There’s a series called The Perfect Run that’s basically this. Pretty well written for the genre (I’ve only read the first book). Cyberpunk, fantasy, LitRPG type story off royal road.

https://www.goodreads.com/series/329243-the-perfect-run https://www.royalroad.com/fiction/36735/the-perfect-run

Yeah you’ve gotten the idea I was going for. The workflow of gerrit incentivises forming commits with single ideas. It’s not always squash or never squash, it’s squash when it makes sense to. You still have to stay on top of reviews to get devs to do it, but it’s so much easier that there’s no excuse.

For CI, it depends how you set it up but usually you would test each commit in the relation chain to ensure they’re cherry pickable, back portable. It also helps to push devs to make commits single well contained ideas. Patches higher up in the relation chain will build with the patches below it.

Often you’ll push a relation chain up, get reviews on all of them, get green from CI on all, and then merge them all together. Normally you would set it up to rebase the commits and ff merge them to main.

I really like the idea of the divine concorde. Lots of room for ideas of old religious wars over encroachments on aspects. Secretive cults take on more importance. Sects of religious zealots who root out cults and believers of new gods. Sounds fun :D.

The answer is Gerrit and learning interactive rebase.

The key thing gerrit provides is relation chains. You can push to the server your local branch and it will make a “patch” (like a pull request) for each of the commits in your branch. The patches are automatically put into a relation chain which lets reviewers go through them in sequence. Also your CI can test them together.

The idea is you need to locally make your commits ready for master. This is where interactive rebase comes in. You’ll have a normal local working branch and when you’re ready for review you use interactive rebase to squash some commits together, redo the commit message on some, change the order, etc. Basically you clean up your working branch into a series of commits ready for main.

Being able to easily push a relation chain of reviews up makes it way easier to make commits that land on main that just do one thing.

The second part of the solution gerrit provides is patchsets. When you need to edit a patch to deal with review comments, you actually rewrite your local history using git commit —amend or interactive rebase and push to gerrit again. In gerrit this will make a new patchset of your patch that you can diff between, see comments on, etc. It works very well for dealing with review feedback and for reviewers to quickly rereview.

It achieves this magic through a change-id that is added via git hook to the commit message. Even if you rewrite your history and your commit id changes it will still consider the rewritten commit to be the same patch as long as the change-id stays the same.

It’s pretty hard to just explain it like this. Using the workflow for a bit makes it much easier to see the value it has.