The Perfect Commit
I am a firm believer that a commit should rarely be more than a couple minutes of work. When I go to git-blame, I want the commit message to be the why of this specific change. When I git blame and find a commit that&#x27;s thousands of lines I wonder why we&#x27;re even using git at that point and not just saving zips.<p>The proponents of PR Squashes irk me. You&#x27;re losing all the value of git. In the future when I&#x27;m hunting down a problem I almost never care about what feature or fix this was a part of - e.g. the PR - I care entirely about the context of the developers mind when he committed that specific line of code.<p>In the rare case you do actually care what PR a commit is from, GitHub&#x27;s search will tell you.[1]. There&#x27;s no need to put that information in a commit at all.<p>I was recently hunting down the reason for a single ! casting a string to a bool. The blame on the file lead to a large commit with details about the project, but nothing about why that specific line of code was changed.<p>Was it an accident? Did it serve an actual purpose? I might never know.<p>Commits are cheap. Blames are easy. There&#x27;s zero need to try to keep your tree &quot;looking nice&quot;.<p>1: <a href="https:&#x2F;&#x2F;github.com&#x2F;donatj&#x2F;CsvToMarkdownTable&#x2F;search?q=f4c167a1cb391b80fcff0f071b9570a6995f9bbc&amp;type=issues" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;donatj&#x2F;CsvToMarkdownTable&#x2F;search?q=f4c167...</a>