The more you understand the inner workings of git, the more you realize all the people who pointed and laughed at GitHub for being a centralized place for everyone's git repos were right.
This is especially true now that GitHub has reached 0 nines of uptime.
I also don't like that everything became all about pull requests instead of commits. Nobody reads the commit messages these days. They might as well not be there.
If I wrote all my commit messages at work by rolling my face across the keyboard, not one person would notice.
And then, because so many people like to squash-merge GitHub PRs because it "keeps the history clean", you run into the problem where `git blame` points at the squashed commit with the frankenstein message rather than the specific self-contained commit I made.
And since, as I mentioned above, nobody looks at the commits inside the PR, the context is effectively lost.
The second thing that bothers me about GitHub squashed PR commits is that someone is gonna cherry-pick them at some point because "it's so much cleaner than merging the original branch in".
But then when the branches need to be merged, you get conflicts because some commits are applied out of order and multiple times because a cherry-pick is a whole different commit. If you use merge commits, this doesn't happen because each commit is only applied once.
In GitHub's defense, git is such a pain in the ass to learn and GitHub gives you useful abstractions if you want to defer learning about it. That can be useful.
I've been noticing a trend where engineers want to ignore details about a lot of things, though: git, infrastructure, deployment, observability, scale, latency, customers, stakeholders, the consequences of the systems they're building, even the code they're writing.
@jamie Only if the squasher isn't mindful about what they're squashing and how they update the commit messages.
I'm guessing you're finding: they're not.
@elight Oh, my friend, the fact that you think they're spending time squashing their own commits on their branch and updating their commit messages is delightfully optimistic. I truly mean this. I wish I could share in your optimism.
What I mean is using GitHub's "Squash and Merge" feature. It simply glorps all the commit messages into something that reads like gruel tastes. This is an actual commit message on my company's main app's `main` branch from a PR squashed this way:
Feel this in my bones. I will often suggest reviewers walk my PRs' commits instead of looking for meaning in a wall of red and green File Changes.
Jamie Gaskins
ohir
__Miguel_
Robb Kidd
Evan Light