Hacker News Reader

Comment by fleitz | Hacker News Reader

Blame is pointless, and needed only for pathological organizations. The point of these tools is not to assign blame but to find the last working revision of the code. If a commit inherits from multiple commits then there could be multiple working last revisions.

Think of it like sailing when the mast breaks, you don't who last touched the mast, you care how to get the mast back up.

In truth the totality of world events leading up to the moment the mast broke is what lead it to break. This is not important, what is important is how to right it.

If the question is viewed in terms of righting the ship then the point is to identify the last revision that worked, conversely the 'broken' revision is the next one.

Realistically, to solve the problem you'd want a genetic algorithm that could turn on and off each change in each revision to find the combination that yields the most fit iteration of the code.

View on HN

Blame is most useful after I've figured out what the bug is, and I want to understand why the change was originally made, and to see the other changes that were made to the source tree at the same time. So it's not the author of the commit which I'm interested in blaming, but to see what the reasoning behind the change originally was, by seeing the entire commit which included a particular on a line.

As far as the stack exchange comment that it's useless because what you usually see is white space fixups, (a) that's why I fix up the whitespace before I commit the final patch into the source tree, and/or insist that those problems be fixed before I pull a commit, and (b) this is why a strongly discourage whitespace-only cleanup patches. (Or checkpatch.pl style changes, in general.) With a little discipline, "git blame" can be incredibly useful.

[edit] Whoops, meant to post this one level up.

Blame information is useful, not for pointing fingers, but for reasoning about changes. Often, I'll be browsing code, see something change, blame that line, then go and read that entire revision so I can find out why the line was changed. Normally for me, my goal is to find out the new argument ordering or whatever so I can continue writing my code using the new pattern.

Wait, what? My most common use case for blame is finding out who to ask about some code that I don't fully understand. Often a quick "git blame" and a short conversation can save a lot of time.

Try that on a code base that's 10 years old and the one who wrote the code, including the rest of the core team, probably changed jobs several times already.

Yes, it doesn't always work and is not always feasible.

But there are plenty of occasions where it is, because the changes broke the system. A broken system is not going to sit around for 10 years.

Pointless? You seem too caught up in the meaning of the word 'blame'. Maybe you should think of it as 'annotate', instead.

There are plenty of times where I want to find the changeset that last touched a line of code so I can read its commit message, find an associated bug tracker ticket, etc. What do these uses have to do with the last working revision of a project?

As others have said, it is often very important (at least when working in a collaborative manner on real-world complex code bases) to work out who added code and more importantly why it either exists or was written that way. More likely than not (assuming it's a fairly high-quality code base) there's an edge case somewhere that it's dealing with.

Bisecting to the revision before it broke doesn't tell you anything about this.

Ideally, there should be loads of comments too, but then, that doesn't happen nearly as often as it should in the real world...

I use git blame to find out who to talk to before doing a refactor. Often when I see something as clumsy, there's a good reason for it and it is nice to know who to ask.

Your comment reminded me of Chesterton's Fence http://epicureandealmaker.blogspot.com/2012/03/chesterton-fe... It has been written about a few hundred times in various blogs. Basically, if you don't see a reason, before you make changes think harder until you do.

git config alias.praise blame

Bazaar actually has blame, praise and annotate, all synonyms!

So does Subversion :-)

Reply on news.ycombinator.com