This so much. Another pet peeve of mine: GitHub is terrible for the workflow that Git was originally designed for. Specifically, the issue that there's no good way to review patch series. The key here is presenting a series of patches as a whole, but allowing reviews on individual commits of the series.
This is my second or third biggest problem with GitHub. If I want to submit a patch—the thing that Git was made for—I cannot use GitHub to do it. Assuming one has already gone through the "create a GitHub account" step, my closest option is to go to github.com to create a completely unnecessary on-GitHub "fork", go back to my local copy to add that remote and push to it, and then go back to the github.com and click around to submit a pull request.
Pull requests in Git were designed for trusted, frequent collaborators. I.e., project maintainers that are routinely syncing with one another. It's not supposed to be the preferred mechanism for ordinary contributions, and certainly not for drive-by contributions.
My biggest gripe, though, is that the on-GitHub fork from the first paragraph will live on in my namespace forever, unless I manually prune it. And even if I do prune it, I still have no way to control the fact that GitHub has silently set up a social networking timeline to broadcast a centralized index of all this activity to anyone and everyone, without asking me, and without a way to manage the stuff that goes into the timeline, control who it's shared with, or turn it off completely.
Not really. You cannot comment on the commit message itself. And, if I'm not mistaken, changes made in one commit that are undone in a subsequent commit won't show up even if the files view if filtered by commit.
Also, it's difficult to tell which comment is associated with which commit.
I don't think I ever factor in commit messages into my code reviews. I may look at the commit history if I want to see how they experimented implementing the feature, but I only care about the end goal and the code I will be merging in at the end.
The issue is that Github actually discourages reviewing by commit because it makes it difficult to do so. Though there are those who are only interested in the overall diff, there are others who want to be able to maintain a clean and informative history via version control. When the review system makes it difficult to ensure that's the case, then then version control history cannot be maintained.
Precisely. We're in a vicious cycle where most people using Git don't use what ought to be Git best practices for most serious large scale projects (clean history with self-contained logical commits and good commit descriptions) because GitHub makes it so difficult to do this. And to be fair, GitLab really isn't much better in this department.
And there isn't enough pressure on GitHub or GitLab to clean up their act because most people don't even know what they're missing. And so the cycle continues.
If you use squash and merge this won't be a problem, you will have a "clean history with self-contained logical commits and good commit history", and intermediary commits won't matter anyway.
Some features take more than a single logical commit to implement. Looking at the git mailing list, I see patch series containing anywhere from 1 to 10 commits (with some as many as 15 commits).
Also, having a single commit touching many parts of the code makes it harder to revert due to a greater chanche of conflicts with other commits.
