4 ms·

People are definitely looking at history when running git blame on a file. We want to know exactly who, when and why a change was made. Squashing down a PR to

People are definitely looking at history when running git blame on a file. We want to know exactly who, when and why a change was made. Squashing down a PR to a single commit erases all of that history and we have no idea when the change was made, who made it, who to talk to, or why it was made other than it was part of a larger feature set. It might work fine for smaller PRs, but where I am we have multiple teams each working on a task that can take months to complete with lots of testing before it's ready to merge into a release branch.

globular-toast 7y ago
Git blame is very useful, yes. But what do you need to know? Do you need to know that Josh made a commit called "fixes" at 3pm on a Wednesday (while it was raining), or do you want to know what feature this commit was part of? I don't argue for squashing down the whole branch into one commit. That's silly and could be throwing away valuable information. But cleaning up the history using rebasing is still possible. We use "fixup!" commits so that a simple autosquash does the right thing most of the time. I've actually had developers undo over-eager squashing before and introduced them to both the reflog and interactive rebasing. They are shocked the first time they learn to "undo" a rebase, but it's a liberating experience to actually understand git.
- _ikke_ 7y ago
  When people talk about squashing branches, it means squashing all commits into a single commit (git merge --squash, or using the squash feature of github / gitlab / hosted-git-solution). The reason you use blame is to find the exact commit that changed a specific line, and hope to find the rational / decisions that lead up to this change, assuming people are disciplined enough to document that in their commit messages. If not, maybe you could even ask Josh if they still remember why they changed things a certain way. Many developers commit append-only until their feature works, which means there are a lot of noise commits in between, which they don't (know how to) clean up. Rather than having all this noise, projects opt to squash the commits instead.

globular-toast 7y ago

Git blame is very useful, yes. But what do you need to know? Do you need to know that Josh made a commit called "fixes" at 3pm on a Wednesday (while it was raining), or do you want to know what feature this commit was part of? I don't argue for squashing down the whole branch into one commit. That's silly and could be throwing away valuable information. But cleaning up the history using rebasing is still possible. We use "fixup!" commits so that a simple autosquash does the right thing most of the time. I've actually had developers undo over-eager squashing before and introduced them to both the reflog and interactive rebasing. They are shocked the first time they learn to "undo" a rebase, but it's a liberating experience to actually understand git.

_ikke_ 7y ago
When people talk about squashing branches, it means squashing all commits into a single commit (git merge --squash, or using the squash feature of github / gitlab / hosted-git-solution). The reason you use blame is to find the exact commit that changed a specific line, and hope to find the rational / decisions that lead up to this change, assuming people are disciplined enough to document that in their commit messages. If not, maybe you could even ask Josh if they still remember why they changed things a certain way. Many developers commit append-only until their feature works, which means there are a lot of noise commits in between, which they don't (know how to) clean up. Rather than having all this noise, projects opt to squash the commits instead.