6 ms·

By the way, git blaming is really misunderstood by a lot of people; its NOT about who did it, its about which commit is to blame -- that's different.

markerz 2y ago
Ideally, you find the context for why a change was made
gleenn 2y ago
Isn't this sort of an inconsequential point? The commit still has one and only one author and that's almost certainly what I'm looking for so I know who to go ask questions about their code. I also use it to find the commit but less frequently.
- lubutu 2y ago
  I mean, no. If you work on a codebase that's been going for more than a few years, the author likely doesn't even work there anymore. The commit is the important thing.
  - iterance 2y ago
    Frankly the commit message is usually the important thing. I care about why a change happened. Give me a Jira ticket, or a line of reasoning, or some documentation. I need to know this far more often than I care who literally typed the code in the computer.
    - globular-toast 2y ago
      You also shouldn't assume the commit author is the same person who literally typed the code. Git is a version control system, not an audit trail.
- rav 2y ago
  On a small team I usually already know who wrote the code I'm reading, but it's nice to see if a block of code is all from the same point in time, or if some of the lines are the result of later bugfixing. It's also useful to find the associated pull request for a block of code, to see what issues were considered in code review, to know whether something that seems odd was discussed or glossed over when the code was merged in the first place.
  - mckn1ght 2y ago
    I find the GitHub blame view indispensable for this kind of code archeology, as they also give you an easy way to traverse the history of lines of code. In blame, you can go back to the previous revision that changed the line and see the blame for that, and on and on. I really want to find or build a tool that can automatically traverse history this way, like git-evolve-log.
    - eichin 2y ago
      I've been carrying around a copy of "git blameall" for years - looks like https://github.com/gnddev/git-blameall https://github.com/gnddev/git-blameall is the same one - that basically does this, but keeps it all interleaved in one output (which works pretty well for archeology, especially if you're looking at "work hardened" code.) (Work hardening is a metalworking term where metal bent back and forth (or hammered) too much becomes brittle; an analogous effect shows up in code, where a piece of code that has been bugfixed a couple of times will probably be need more fixes; there was a published result a decade or so back about using this to focus QA efforts...)
    - weaksauce 2y ago
      there is https://github.com/emacsmirror/git-timemachine https://github.com/emacsmirror/git-timemachine which is really nice if you use emacs.
    - follower 2y ago
      "Cregit" tool might be of interest to you, it generates token-based (rather than line-based) git "blame" annotation views: https://github.com/cregit/cregit https://github.com/cregit/cregit Example output based on Linux kernel @ "Cregit-Linux: how code gets into the kernel": https://cregit.linuxsources.org/ https://cregit.linuxsources.org/ I learned of Cregit recently--just submitted it to HN after seeing multiple recent HN comments discussing issues related to line-based "blame" annotation granularity: "Cregit-Linux: how code gets into the kernel": https://news.ycombinator.com/item?id=43451654 https://news.ycombinator.com/item?id=43451654
- sshine 2y ago
  No, commits can be co-authored. And the committer and author don’t even need to be the same! But the point, as I read it, is: what matters is the context, i.e. if a line is faulty, how did things look like when it wasn’t faulty? The commit’s content is more often more important than the committer, although the committer is useful because you can ask them if they’re still around.
- lionkor 2y ago
  No, if your commits are meaningful and have plenty of context, like they should, then you are not looking for the author. Instead, you are looking for "why is this here", and the commit should tell you.
- pjc50 2y ago
  At my last workplace, the codebase was about 25 years old, there were three of us, and one of us was the original author. You could simply guess "Gerald wrote this" and you'd be right nine times out of ten. However, it turns out that software developers have finite memory themselves, and svn blame was useful in tracing a line of code back to the original ticket. Linking a line of code back to the commit is useful even if you can't ask the author about it. It tells you what other lines of code are involved and what the overall purpose is. It's significantly more useful if you can link it into documentation outside the code: ticketing systems, requirements docs, etc. The main limit to svn blame in that situation was that quite often it would hit commit 1, when the codebase had been imported from Visual SourceSafe.
orthoxerox 2y ago
Isn't that what git bisect is for?
- davely 2y ago
  Sometimes you don't know which commit actually caused the problem. e.g., you realize that something broke A/B test logic on Friday. Sure, there are Jira tickets, but that's slow and annoying to dig through. There are commit messages, but things get squashed, etc. Plus, if you work in a monorepo with about 60 PRs a day, it's hard to know if it was your code or an associated library someone touched. That's exactly when git bisect helps. It quickly narrows down which commit introduced the bug when you don't know where to start looking. Once bisect identifies the problematic commit, you can then use git blame (if needed) to see who made those specific changes. Edit: Cleaned up what I was saying to hopefully avoid confusion.
  - ants_everywhere 2y ago
    I'm not quite sure what you're saying, but blame just tells you the last person and commit to change a line. If you want to know which commit actually caused a problem you would use bisect. That may be what you're saying, but it sounded a bit like you are saying blame is better for tracking the culprit commit.
- recursive 2y ago
  Bisect is for finding behavior changes in O(log n) operations. Blame is for finding the last change to a line in one operation.
kemitchell 2y ago
I have seen `git blame` used to blame specific people. I've seen it work. Some of those people deserved some blame. The manpage explains what the command does. How and why it's used is up to the user.
- lelandfe 2y ago
  Alternatively git praise https://github.com/ansman/git-praise https://github.com/ansman/git-praise
  - einpoklum 2y ago
    Now _that_ is one of the best two-liners I've ever seen!
  - what 2y ago
    Why wouldn’t you just set an alias in your global git config for this?
    - account42 2y ago
      You can't put an alias on your CV.
    - dspillett 2y ago
      Perhaps the author intended further additions, perhaps transforming the output to apply filters or add spurious superlatives for humour value (“Great work on line 420, User6942!”).
wilg 2y ago
Many people enjoy pretending that the term "blame" in "git blame" is not a funny little programmer joke that we don't have to be upset about.
- remram 2y ago
  It's funny because it always ends up telling me I did it.
  - wilg 2y ago
    One of the most delightful outcomes of having the silly name!
ants_everywhere 2y ago
I'm pretty sure it's about who wrote the code. 'git blame' is named after the subversion and CVS blame features that do the same thing. Subversion docs are clear that it's a snarky name and that 'svn praise' and 'svn annotate' are neutral synonyms. Perhaps someone familiar with CVS can comment on its history there since it seems to be the first source control to add it. EDIT: and one of the main reasons it's a useful feature is it tells you who to talk to to understand a piece of code, or to coordinate a roll back, or to do any other sort of communication. It probably matters more in a big company where code is changing frequently and you're unlikely to know everyone and what they're working on.
- dvt 2y ago
  > EDIT: and one of the main reasons it's a useful feature is it tells you who to talk to to understand a piece of code, or to coordinate a roll back, or to do any other sort of communication. It probably matters more in a big company where code is changing frequently and you're unlikely to know everyone and what they're working on. It's actually a pretty awful feature because it misses so much context. I've been blamed before for changes which were technically my fault, but while my code was to spec, some unrelated part of the code I was interacting with was not (iirc it was some multi-threaded nonsense like a race condition or something). It was a super-stressful week of constantly having to defend my design decisions and white-boarding my thought process (think of the "am I taking crazy pills?!?" scene in Zoolander) as my senior coworker tried to gaslight and throw me under the bus. Maybe I've had a uniquely bad experience with it, but I've vowed to never use it (as a way to attribute `blame`). Code should be holistically understood and it's your job as a technical leader to know how the parts move, resolve issues without drama, and make sure your whole team is on the same page: this is a cohesive team, not an adversarial dick-measuring contest.
  - cdogl 2y ago
    That sounds like an awful workplace culture. I doubt the name of the git command is responsible, though.
  - opello 2y ago
kazinator 2y ago
git bisect is about which commit is to blame for a reproducible problem. git blame is about which author most recently touched each line (in what commit); i.e. is to "blame" for that line having its current content. You're right in that git blame is most useful for finding which commit touched a line. What was done in the commit is more important than who did it. git blame is very useful even in a solo project where you already know that you wrote every commit.
- Lanolderen 2y ago
  Unless you get lazy like me and start committing only out of shame once the modified file count reaches close to triple digits or prior to doing very sketchy changes.
  - dspillett 2y ago
    True, and I'm guilty three too, but there is a limited amount we can expect toolmakers to do to protect those of us who misuse their tools :)
  - kazinator 2y ago
    Is this something you do in a brand new project whose organization, direction and overall requirements are not clear? Or persistently? There is such a concept as a brand new project not requiring version control until it hits a certain stage: you know it when you get there.
    - Lanolderen 2y ago
      Persistently. My solo projects aren't particularly complex though so I haven't really wasted any time by not being able to use git history for debugging. I currently have 38 files modified on my solo work project. If I'm in a team I keep it somewhat tidy but solo I only treat commits as manual save points I use only when my spidey senses tingle or when I'm about to refactor something that works fine as it is. Also when I'm done with a large part of the SW so the next dev at least has some rough timeline for what got added when and how many times it was majorly iterated. It's not a good habit but it has yet to bite me in the ass so I learn. Edit: A large part of the reason now that I think about it is that I don't work off real tickets but just bugs I notice or things that get mentioned on the current solo work project. In a team I can just dissect the ticket and am forced to do only that ticket on the branch whereas solo I'm just jumping all over the place. Sometimes I'll do thing X partway, start considering options and in the meantime do thing Y so it's a mess but the tasks get done so.. For context the project is 1 year old developed from 0 by me. Essentially an internal log parsing and analysis tool for a couple formats. Nothing particularly complex.
TZubiri 2y ago
No. You are thinking of git bisect
- lionkor 2y ago
  No, bisect is not blame but for commits. Blame shows you which COMMIT is to blame. That's my point.
  - TZubiri 2y ago
    True Git log gives the author (et al) given a commit. Git blame gives the commit given the line and file. Worth noting that annotate and praise were added to address the semantics, regardless of whether they were the original intent or not
- account42 2y ago
  Bisect shows which commit is responsible for a yes/no behavior change. Blame shows which commit is responsible for a line of code. Both are useful for finding the responsible commit but for different things.
gwbas1c 2y ago
BTW, one of the more frustrating things about "git blame" comes about when cleaning up an old codebase: In my current job I had to move a lot of files, combine repos, reformat code, ect, ect. "git blame" and similar tools often always show my name, even though I didn't write the code.
- alisonatwork 2y ago
  Most places I worked have a blame.ignoreRevsFile[0] somewhere on the top level to inhibit this. It's a bit awkward because first you need to commit, then you need commit again to update the commit hash in the ignore revs file, but it's great for filtering out pure refactor churn. [0] https://git-scm.com/docs/git-blame#Documentation/git-blame.txt-blameignoreRevsFile https://git-scm.com/docs/git-blame#Documentation/git-blame.t...
- Izkata 2y ago
  git log/blame have -C and -M to follow modified lines across files. Unlike other version control, you don't have to have used a special command to rename files, because it doesn't track files that way in the first place. The maximum -C can even look for sources in other commits.
- graemep 2y ago
  I was thinking that I would really like a tool that shows the history of bad code, and who actually wrote it and amended it, not just who last changed it. Particularly so if I can see that someone wrote bad code, so I can review the rest of their code.
- follower 2y ago
  "Cregit" tool might be of interest to you, it generates token-based (rather than line-based) git "blame" annotation views: https://github.com/cregit/cregit https://github.com/cregit/cregit Example output based on Linux kernel @ "Cregit-Linux: how code gets into the kernel": https://cregit.linuxsources.org/ https://cregit.linuxsources.org/ I learned of Cregit recently--just submitted it to HN after seeing multiple recent HN comments discussing issues related to line-based "blame" annotation granularity: "Cregit-Linux: how code gets into the kernel": https://news.ycombinator.com/item?id=43451654 https://news.ycombinator.com/item?id=43451654 Of course, in your situation I guess such a tool would only help if other people use it. :D
LarsenCC 2y ago
True.

markerz 2y ago

Ideally, you find the context for why a change was made

gleenn 2y ago

Isn't this sort of an inconsequential point? The commit still has one and only one author and that's almost certainly what I'm looking for so I know who to go ask questions about their code. I also use it to find the commit but less frequently.

lubutu 2y ago
I mean, no. If you work on a codebase that's been going for more than a few years, the author likely doesn't even work there anymore. The commit is the important thing.
- iterance 2y ago
  Frankly the commit message is usually the important thing. I care about why a change happened. Give me a Jira ticket, or a line of reasoning, or some documentation. I need to know this far more often than I care who literally typed the code in the computer.
  - globular-toast 2y ago
    You also shouldn't assume the commit author is the same person who literally typed the code. Git is a version control system, not an audit trail.
rav 2y ago
On a small team I usually already know who wrote the code I'm reading, but it's nice to see if a block of code is all from the same point in time, or if some of the lines are the result of later bugfixing. It's also useful to find the associated pull request for a block of code, to see what issues were considered in code review, to know whether something that seems odd was discussed or glossed over when the code was merged in the first place.
- mckn1ght 2y ago
  I find the GitHub blame view indispensable for this kind of code archeology, as they also give you an easy way to traverse the history of lines of code. In blame, you can go back to the previous revision that changed the line and see the blame for that, and on and on. I really want to find or build a tool that can automatically traverse history this way, like git-evolve-log.
  - eichin 2y ago
    I've been carrying around a copy of "git blameall" for years - looks like https://github.com/gnddev/git-blameall https://github.com/gnddev/git-blameall is the same one - that basically does this, but keeps it all interleaved in one output (which works pretty well for archeology, especially if you're looking at "work hardened" code.) (Work hardening is a metalworking term where metal bent back and forth (or hammered) too much becomes brittle; an analogous effect shows up in code, where a piece of code that has been bugfixed a couple of times will probably be need more fixes; there was a published result a decade or so back about using this to focus QA efforts...)
  - weaksauce 2y ago
    there is https://github.com/emacsmirror/git-timemachine https://github.com/emacsmirror/git-timemachine which is really nice if you use emacs.
  - follower 2y ago
    "Cregit" tool might be of interest to you, it generates token-based (rather than line-based) git "blame" annotation views: https://github.com/cregit/cregit https://github.com/cregit/cregit Example output based on Linux kernel @ "Cregit-Linux: how code gets into the kernel": https://cregit.linuxsources.org/ https://cregit.linuxsources.org/ I learned of Cregit recently--just submitted it to HN after seeing multiple recent HN comments discussing issues related to line-based "blame" annotation granularity: "Cregit-Linux: how code gets into the kernel": https://news.ycombinator.com/item?id=43451654 https://news.ycombinator.com/item?id=43451654
sshine 2y ago
No, commits can be co-authored. And the committer and author don’t even need to be the same! But the point, as I read it, is: what matters is the context, i.e. if a line is faulty, how did things look like when it wasn’t faulty? The commit’s content is more often more important than the committer, although the committer is useful because you can ask them if they’re still around.
lionkor 2y ago
No, if your commits are meaningful and have plenty of context, like they should, then you are not looking for the author. Instead, you are looking for "why is this here", and the commit should tell you.
pjc50 2y ago
At my last workplace, the codebase was about 25 years old, there were three of us, and one of us was the original author. You could simply guess "Gerald wrote this" and you'd be right nine times out of ten. However, it turns out that software developers have finite memory themselves, and svn blame was useful in tracing a line of code back to the original ticket. Linking a line of code back to the commit is useful even if you can't ask the author about it. It tells you what other lines of code are involved and what the overall purpose is. It's significantly more useful if you can link it into documentation outside the code: ticketing systems, requirements docs, etc. The main limit to svn blame in that situation was that quite often it would hit commit 1, when the codebase had been imported from Visual SourceSafe.

orthoxerox 2y ago

Isn't that what git bisect is for?

davely 2y ago
Sometimes you don't know which commit actually caused the problem. e.g., you realize that something broke A/B test logic on Friday. Sure, there are Jira tickets, but that's slow and annoying to dig through. There are commit messages, but things get squashed, etc. Plus, if you work in a monorepo with about 60 PRs a day, it's hard to know if it was your code or an associated library someone touched. That's exactly when git bisect helps. It quickly narrows down which commit introduced the bug when you don't know where to start looking. Once bisect identifies the problematic commit, you can then use git blame (if needed) to see who made those specific changes. Edit: Cleaned up what I was saying to hopefully avoid confusion.
- ants_everywhere 2y ago
  I'm not quite sure what you're saying, but blame just tells you the last person and commit to change a line. If you want to know which commit actually caused a problem you would use bisect. That may be what you're saying, but it sounded a bit like you are saying blame is better for tracking the culprit commit.
recursive 2y ago
Bisect is for finding behavior changes in O(log n) operations. Blame is for finding the last change to a line in one operation.

kemitchell 2y ago

I have seen `git blame` used to blame specific people. I've seen it work. Some of those people deserved some blame. The manpage explains what the command does. How and why it's used is up to the user.

lelandfe 2y ago
Alternatively git praise https://github.com/ansman/git-praise https://github.com/ansman/git-praise
- einpoklum 2y ago
  Now _that_ is one of the best two-liners I've ever seen!
- what 2y ago
  Why wouldn’t you just set an alias in your global git config for this?
  - account42 2y ago
    You can't put an alias on your CV.
  - dspillett 2y ago
    Perhaps the author intended further additions, perhaps transforming the output to apply filters or add spurious superlatives for humour value (“Great work on line 420, User6942!”).

wilg 2y ago

Many people enjoy pretending that the term "blame" in "git blame" is not a funny little programmer joke that we don't have to be upset about.

remram 2y ago
It's funny because it always ends up telling me I did it.
- wilg 2y ago
  One of the most delightful outcomes of having the silly name!

ants_everywhere 2y ago

I'm pretty sure it's about who wrote the code. 'git blame' is named after the subversion and CVS blame features that do the same thing. Subversion docs are clear that it's a snarky name and that 'svn praise' and 'svn annotate' are neutral synonyms. Perhaps someone familiar with CVS can comment on its history there since it seems to be the first source control to add it. EDIT: and one of the main reasons it's a useful feature is it tells you who to talk to to understand a piece of code, or to coordinate a roll back, or to do any other sort of communication. It probably matters more in a big company where code is changing frequently and you're unlikely to know everyone and what they're working on.

dvt 2y ago
> EDIT: and one of the main reasons it's a useful feature is it tells you who to talk to to understand a piece of code, or to coordinate a roll back, or to do any other sort of communication. It probably matters more in a big company where code is changing frequently and you're unlikely to know everyone and what they're working on. It's actually a pretty awful feature because it misses so much context. I've been blamed before for changes which were technically my fault, but while my code was to spec, some unrelated part of the code I was interacting with was not (iirc it was some multi-threaded nonsense like a race condition or something). It was a super-stressful week of constantly having to defend my design decisions and white-boarding my thought process (think of the "am I taking crazy pills?!?" scene in Zoolander) as my senior coworker tried to gaslight and throw me under the bus. Maybe I've had a uniquely bad experience with it, but I've vowed to never use it (as a way to attribute `blame`). Code should be holistically understood and it's your job as a technical leader to know how the parts move, resolve issues without drama, and make sure your whole team is on the same page: this is a cohesive team, not an adversarial dick-measuring contest.
- cdogl 2y ago
  That sounds like an awful workplace culture. I doubt the name of the git command is responsible, though.
- opello 2y ago

kazinator 2y ago

git bisect is about which commit is to blame for a reproducible problem. git blame is about which author most recently touched each line (in what commit); i.e. is to "blame" for that line having its current content. You're right in that git blame is most useful for finding which commit touched a line. What was done in the commit is more important than who did it. git blame is very useful even in a solo project where you already know that you wrote every commit.

Lanolderen 2y ago
Unless you get lazy like me and start committing only out of shame once the modified file count reaches close to triple digits or prior to doing very sketchy changes.
- dspillett 2y ago
  True, and I'm guilty three too, but there is a limited amount we can expect toolmakers to do to protect those of us who misuse their tools :)
- kazinator 2y ago
  Is this something you do in a brand new project whose organization, direction and overall requirements are not clear? Or persistently? There is such a concept as a brand new project not requiring version control until it hits a certain stage: you know it when you get there.
  - Lanolderen 2y ago
    Persistently. My solo projects aren't particularly complex though so I haven't really wasted any time by not being able to use git history for debugging. I currently have 38 files modified on my solo work project. If I'm in a team I keep it somewhat tidy but solo I only treat commits as manual save points I use only when my spidey senses tingle or when I'm about to refactor something that works fine as it is. Also when I'm done with a large part of the SW so the next dev at least has some rough timeline for what got added when and how many times it was majorly iterated. It's not a good habit but it has yet to bite me in the ass so I learn. Edit: A large part of the reason now that I think about it is that I don't work off real tickets but just bugs I notice or things that get mentioned on the current solo work project. In a team I can just dissect the ticket and am forced to do only that ticket on the branch whereas solo I'm just jumping all over the place. Sometimes I'll do thing X partway, start considering options and in the meantime do thing Y so it's a mess but the tasks get done so.. For context the project is 1 year old developed from 0 by me. Essentially an internal log parsing and analysis tool for a couple formats. Nothing particularly complex.

TZubiri 2y ago

No. You are thinking of git bisect

lionkor 2y ago
No, bisect is not blame but for commits. Blame shows you which COMMIT is to blame. That's my point.
- TZubiri 2y ago
  True Git log gives the author (et al) given a commit. Git blame gives the commit given the line and file. Worth noting that annotate and praise were added to address the semantics, regardless of whether they were the original intent or not
account42 2y ago
Bisect shows which commit is responsible for a yes/no behavior change. Blame shows which commit is responsible for a line of code. Both are useful for finding the responsible commit but for different things.

gwbas1c 2y ago

BTW, one of the more frustrating things about "git blame" comes about when cleaning up an old codebase: In my current job I had to move a lot of files, combine repos, reformat code, ect, ect. "git blame" and similar tools often always show my name, even though I didn't write the code.

alisonatwork 2y ago
Most places I worked have a blame.ignoreRevsFile[0] somewhere on the top level to inhibit this. It's a bit awkward because first you need to commit, then you need commit again to update the commit hash in the ignore revs file, but it's great for filtering out pure refactor churn. [0] https://git-scm.com/docs/git-blame#Documentation/git-blame.txt-blameignoreRevsFile https://git-scm.com/docs/git-blame#Documentation/git-blame.t...
Izkata 2y ago
git log/blame have -C and -M to follow modified lines across files. Unlike other version control, you don't have to have used a special command to rename files, because it doesn't track files that way in the first place. The maximum -C can even look for sources in other commits.
graemep 2y ago
I was thinking that I would really like a tool that shows the history of bad code, and who actually wrote it and amended it, not just who last changed it. Particularly so if I can see that someone wrote bad code, so I can review the rest of their code.
follower 2y ago
"Cregit" tool might be of interest to you, it generates token-based (rather than line-based) git "blame" annotation views: https://github.com/cregit/cregit https://github.com/cregit/cregit Example output based on Linux kernel @ "Cregit-Linux: how code gets into the kernel": https://cregit.linuxsources.org/ https://cregit.linuxsources.org/ I learned of Cregit recently--just submitted it to HN after seeing multiple recent HN comments discussing issues related to line-based "blame" annotation granularity: "Cregit-Linux: how code gets into the kernel": https://news.ycombinator.com/item?id=43451654 https://news.ycombinator.com/item?id=43451654 Of course, in your situation I guess such a tool would only help if other people use it. :D

LarsenCC 2y ago

True.