5 ms·

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

by fleitz 14y ago

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.

zachrose 14y ago
git config alias.praise blame
- icebraining 14y ago
  Bazaar actually has blame, praise and annotate, all synonyms!
  - zootm 14y ago
    So does Subversion :-)
pjscott 14y ago
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.
- deleted 14y ago
  [deleted]
- Too 14y ago
  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.
  - megablast 14y ago
    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.
defap 14y ago
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?
- deleted 14y ago
  [deleted]
phamilton 14y ago
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.
- murphysbooks 14y ago
  Your comment reminded me of Chesterton's Fence http://epicureandealmaker.blogspot.com/2012/03/chesterton-fence.html 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.
berkut 14y ago
?? 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...
tytso 14y ago
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.
- CGamesPlay 14y ago
  [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.

by fleitz 14y ago

zachrose 14y ago

git config alias.praise blame

icebraining 14y ago
Bazaar actually has blame, praise and annotate, all synonyms!
- zootm 14y ago
  So does Subversion :-)

pjscott 14y ago

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.

deleted 14y ago
[deleted]
Too 14y ago
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.
- megablast 14y ago
  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.

defap 14y ago

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?

deleted 14y ago
[deleted]

phamilton 14y ago

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.

murphysbooks 14y ago
Your comment reminded me of Chesterton's Fence http://epicureandealmaker.blogspot.com/2012/03/chesterton-fence.html 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.

berkut 14y ago

?? 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...

tytso 14y ago

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.

CGamesPlay 14y ago
[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.