Thing I wish I’d learned sooner about git: it was designed to make patches a first class entity. Trees of objects are indeed the fundamentals, but it’s quite p

Thing I wish I’d learned sooner about git: it was designed to make patches a first class entity. Trees of objects are indeed the fundamentals, but it’s quite possible to detach a commit by formatting it into a patch (“git format-patch”) and sharing it outside of the context of a repo. No ssh required: email it, fax it, print it out and mail it — all the metadata is retained allowing the commit to be reconstituted as if it were git pushed or pulled over TCP. Why is this important? Because code review is about reviewing the changes and applying patches in a different context to where they were authored. If I fix a bug in my repo then you should be able to apply my fix cleanly to a repo in a quite different state that mine was in. We can work on different things in a decentralised way and yet still collaborate. Most people of course don’t work like this. Most people in 2022 will literally share a parent commit from a central repository. They push and pull over the net instead of emailing patches. Their trees are in sync a lot more than the days of patch emailing yore. (Although emailing patches is still used by people who need to exfiltrate a change from some system not blessed with full access credentials to do a real push.) The thing that does still hang around is the idea of a dissociated patch being the unit of a review. Some code review tools don’t really get this right — Gitlab in particular still muddles up the idea of a merge request and a commit. A merge request has a title and a description but so does a commit and yet they are kept separate. You view an MR’s changes as one big patch and these may or may not bear any resemblance to the git commit or commits and their own titles and descriptions. It is as if GitLab’s authors either purposely or naively ignored the idea that git was designed to think in this way from the ground up, and so they implemented a patch-like thing of their own, on top. I’ve also never embraced the idea of commits that are for public consumption and those which are not. In my model, there are no feature branches, only branches that combine different sets of patches. It doesn’t need to be so complex and indeed if you embrace the underlying tool (on which your product is named!) gitlab based git projects would be a bit less special and a bit more like everyone else.