The tweet that started this post off:
Candidate for the worst name of any SCM feature: “blame”. Don’t use it for that.
I was recently watching a couple of conference talks (given by people working at the same company) where the presenters described using the ‘blame’ feature of their version control tool to find the person responsible for a bug so that they could go down to their office and chew them out.
This is not constructive. What are you going to do if that person is on holiday, let the bug fester for a week so you can have the rant when they get back? What if they left the company? Remember that you’re on the same team: you are permitted to fix the bug. Fixing the bug helps you, your team, your company and your customers; complaining at the person who introduces it only helps to poison your relationships with your team. So fix it. That’s not to say the blame feature isn’t useful:
- use it to find out why the change was introduced, which might help you understand what was intended. This is why you write good commit messages.
- use it to find out when the change was introduced, to help you understand the severity of the bug[*]
- yes, use it to find out who made the change, but only if you think that you’re going to learn something from the discussion. Remember, we do not set the bozo bit.
[*] I’ve done this recently. On discovering and isolating a bug, I used git blame to work out whether it was introduced before or after the software was released. Sadly, it was before.
Maybe it should be called “explain”; whatever, do not use your blame feature for blame.
Aside on blame visualisation
If you’re reading this blog post from Black Pixel, hello! Please feel welcome to build this feature into Kaleidoscope without the need to pay me a licensing fee :-)
As code ages, small changes tend to get added here and there. We build an initial implementation of some feature, then discover that there are some edge cases or new ways of using it that we didn’t consider, so little patches get built on. These can overlap or supersede earlier patches, and interact in interesting ways (where “interesting” can be read as “infuriating”, if you like).
What I would find useful is a diff tool that just shows the current state of the file, but uses the z-axis to indicate the age of each line. In the same way that code editors can identify regions for folding using (simulated or actual) depth, they could identify regions of change. This would make it easy to see at a glance how the file has evolved over time, to see where and when changes were needed.
