His paragraph on git was a bit muddled because every goal he had for doing git as he says is achievable without following his rules. Arguably, squashing on mer

His paragraph on git was a bit muddled because every goal he had for doing git as he says is achievable without following his rules. Arguably, squashing on merging and one commit per PR enhance readability and the comprehensibility of the history. The counterargument might be that a single commit can be too large and contain too many logical changes to digest, but in that case the merge commit of 100 commits of a feature branch will still be huge (or you’ll have 100 commits from the branch on main if you rebase). Either way, bisect still works as expected. Putting all the info in the git commit message is a hopeless cause, I think. Even if the message is relatively fulsome, there’s still the context of the change to be found in the JIRA ticket or the Confluence page, and you either leave that out to avoid dead links, in which case context is lost, or you include links that eventually get stale and die. I don’t know of a good solution to this except the fact that large enterprises often have dinosaur systems that are like ancient Mesopotamian pyramids, full of secrets from the past. Honeywell suffered some breaches a couple years ago that necessitated rebuilding a large number of systems, and when they got around to the ClearCase systems still in use by some teams, no one had the intestinal fortitude, let alone the knowledge, to rebuild them. That said, I can’t remember ever seriously digging into the history of a repo to find who implemented something or how it changed to become what it is currently. I’ve worked on very large repos and implemented significant, wide-ranging functionality, and historical exploration never helped me understand the current code or the overall design—if I didn’t have architecture docs I read the code and made my own (in which case I’d rather the effort of a commit message was put into docstrings instead), which did far more to help me grasp a codebase than scrolling through git log. So if I would add one thing to his essay, it would be this: find some undocumented code as document it as you would like it to be. Reading code is an underappreciated skill in our field.