8 ms·

Show HN: git self-blame – Blame yourself for others' mistakes

74 points by jacobevelyn 9y ago

gus_massa 9y ago
What about git-no-blame? Something like your tool but it replace the name with empty spaces instead of your name.
- chhs 9y ago
  Or only the names of people who no longer work at the company
  - AntonyGarand 9y ago
    I suggest making a git blame-nemesis for this purpose
    - Pica_soO 9y ago
      Blame Can_I_do
    - make3 9y ago
      git blame AntonyGarand
    - iamdave 9y ago
      git bofh perhaps? Or are we saving that for the coworker who rejects all of your well commented and wiki'd PRs because it's not in their pet style.
- AntonyGarand 9y ago
  https://github.com/AntonyGarand/git-self-blame https://github.com/AntonyGarand/git-self-blame There you go, forked the project and replaced the "$name" with empty spaces. You would need to rename the from "git-self-blame" to "git-no-blame" though, I can't do it with github at the moment
- pimlottc 9y ago
  “git abstain”?
elcapitan 9y ago
git blame-foreigners When you feel like it's really not you who is the problem.
jacobevelyn 9y ago
Hey HN! Thanks for all the interest! I have somewhat spotty internet now but feel free to ask any questions and I'll do my best to answer them when I can! As a side note, if you're interested in this sort of thing I also wrote out the steps I went through to build this: https://github.com/JacobEvelyn/git-self-blame/blob/master/git-self-blame https://github.com/JacobEvelyn/git-self-blame/blob/master/gi...
gedaxiang 9y ago
I realize this is a bit of a joke, but does anyone else think "blameless" culture has gone a bit too far? I think it's important to stress that everyone makes mistakes, and that it's okay to make mistakes, but at the end of the day, if someone broke something or caused a bug, they should know about it so it doesn't happen again.
- thegeomaster 9y ago
  I think you're right. Here's a personal anecdote that leads me to agree with you. During an internship, I fixed some code style issue in a file that I touched for some unrelated reason. The tests had a blind spot just there, and I didn't manually test after the fix, as it was very minor and I couldn't imagine it causing any problems. But it completely broke the feature, and just testing the most basic user scenario would have revealed the screwup. So the bug made it into staging for a 1.5 MAU web application. Fortunately, manual QA caught it early on, so no real damage was done, but while I didn't suffer any serious consequences, people definitely let me know that my actions were irresponsible. That's had a lasting impact on me. I often recall this anecdote when I catch myself thinking "no need to test that, it was a small change", and it's saved my ass a couple of times since. (Of course, better automation is the right way to avoid these kinds of situations, but that's often not attainable in practice due to a number of constraints.)
  - gmueckl 9y ago
    I guess every developer has to have that moment of hubris in their career. I remember checking in a seemingly trivial change, telling everybody that it works - only to get told in return that it wouldn't even compile, let alone work when the syntax was fixed! Oops... Sure enough, I became much more cautious after that.
  - linuxftw 9y ago
    I don't think your actions were irresponsible. I would assume someone with domain knowledge of the area you changed did a proper code review, especially since you were an intern. If there's not time to write proper tests for code, there's not time for manual testing either. Testing every line of a code change can burn a lot of your time up. Additionally, if a seemingly strange way to do something is necessary for proper function, there should have been a comment in the code to explain why it was doing something in such a particular way.
dh-g 9y ago
Not in the spirit of the project but I would like to see an alias added to the README to replace `git blame` (to run on your own / teammates / friends computers).
- jacobevelyn 9y ago
  Heh, I actually looked into that but it's not so easy. See: https://stackoverflow.com/a/3538791/1103543 https://stackoverflow.com/a/3538791/1103543 So even if this script is the absolute first thing in your $PATH, `git blame` will always call the builtin rather than this. There are probably more involved ways to make this happen the way you want (like create a different `git` program that shells everything out to the real one except the `blame` command) but I wasn't sure I wanted to go down that rabbit hole. Feel free to submit a PR if you find a simpler way though!
  - pcthrowaway 9y ago
    If they're using bash, it shouldn't be so hard. Just put something like this in your/their bashrc git() { if [[ $1 == blame ]]; then shift git self-blame "${@}" else command git "${@}" fi } edit: this isn't 100% perfect as it won't work (but won't break git either) in situations where the user uses a global flag in addition to blame. I've been using git for years though and the only global flag I've used are --version and --help
    - jacobevelyn 9y ago
      Awesome, thanks for sharing! My Bash skills definitely have lots of room for improvement—I think I learned at least three new things from your comment alone. :) I too had never really used global git flags until they came in very handy for `git self-blame`!
- sinisterShroom 9y ago
  https://github.com/ccraciun/git-blame-bob https://github.com/ccraciun/git-blame-bob Just rename/symlink git-blame-bob to git-blame-joe
throwaway2016a 9y ago
Does this mean we should also have "git self-praise" ?
- deleted 9y ago
  [deleted]
PricelessValue 9y ago
I'm spartacus!
SilasX 9y ago
Heh, I have a functionally similar joke project that I named git-upstage: https://github.com/SilasX/git-upstage https://github.com/SilasX/git-upstage The difference is, this one's focus is on stealing credit for others' work -- it squashes a branch into one commit under your name, and backdates it five minutes.
- dpflan 9y ago
  Nice move, preempt this `git-self-blame` tool. Now just make an inverse tool.
  - SilasX 9y ago
    Someone submitted "git blame-someone-else" on another thread, where you give someone else the credit for your own commits, and yes I plugged my project on that one too: https://news.ycombinator.com/item?id=11049993 https://news.ycombinator.com/item?id=11049993
- jacobevelyn 9y ago
  Very cool! I did come across this when I was working on `self-blame` and was (and still am) very impressed!
  - SilasX 9y ago
    Thank you!
pimlottc 9y ago
Alternative name suggestion: “git claim”
syntheticcdo 9y ago
I appreciate the time you took to document your journey in the source file. In most github repos, all we see is the end result of hours or days of work (especially when authors blow away their commit history by squashing prior to to sharing), and the comments that explain everything you tried that /didn't/ work are just as illustrative and educational as knowing what does work.
- jacobevelyn 9y ago
  Thanks, I appreciate the kind words! (And I'm glad at least one person actually read through that.) In this case, I think I was "helped" by the fact that I consider myself relatively inexperienced with both shell scripting and advanced git usage. This gave me an irrational fear that I would publish this repo and get lots of "why didn't you just do X" responses, so writing down my journey was at least one way of showing that I actually tried a few different approaches and while my eventual solution may not be the best I know it's not the worst :)
hinkley 9y ago
Rather than just the author of a line of code, I want git or something git like that allows you to attach commentary to bits of code. For one thing that would allow you to preserve the code reviews but there are bigger reasons for this. In every code base there are at least three generations of styles in the code. The way we want people to write code, the way we used to write it, and the things we wanted the old way to replace. You know, the really terrible code. I find myself from [time] to time wishing I had a way to durably attach commentary to a block of code that doesn’t result in a wall of text and which can’t easily be pruned off in a refactor or a cut and paste. In every team there are people who cut and paste idioms from code they are familiar with into new code. And the code people are [most] familiar with is often the old old way.
- jacobevelyn 9y ago
  Hey there! This is a really neat idea, and I've been kicking around some semi-similar ideas for a while now but haven't done anything with them. Let me know if you want to bounce around some ideas!

74 points by jacobevelyn 9y ago

gus_massa 9y ago

What about git-no-blame? Something like your tool but it replace the name with empty spaces instead of your name.

chhs 9y ago
Or only the names of people who no longer work at the company
- AntonyGarand 9y ago
  I suggest making a git blame-nemesis for this purpose
  - Pica_soO 9y ago
    Blame Can_I_do
  - make3 9y ago
    git blame AntonyGarand
  - iamdave 9y ago
    git bofh perhaps? Or are we saving that for the coworker who rejects all of your well commented and wiki'd PRs because it's not in their pet style.
AntonyGarand 9y ago
https://github.com/AntonyGarand/git-self-blame https://github.com/AntonyGarand/git-self-blame There you go, forked the project and replaced the "$name" with empty spaces. You would need to rename the from "git-self-blame" to "git-no-blame" though, I can't do it with github at the moment
pimlottc 9y ago
“git abstain”?

elcapitan 9y ago

git blame-foreigners When you feel like it's really not you who is the problem.

jacobevelyn 9y ago

Hey HN! Thanks for all the interest! I have somewhat spotty internet now but feel free to ask any questions and I'll do my best to answer them when I can! As a side note, if you're interested in this sort of thing I also wrote out the steps I went through to build this: https://github.com/JacobEvelyn/git-self-blame/blob/master/git-self-blame https://github.com/JacobEvelyn/git-self-blame/blob/master/gi...

gedaxiang 9y ago

I realize this is a bit of a joke, but does anyone else think "blameless" culture has gone a bit too far? I think it's important to stress that everyone makes mistakes, and that it's okay to make mistakes, but at the end of the day, if someone broke something or caused a bug, they should know about it so it doesn't happen again.

thegeomaster 9y ago
I think you're right. Here's a personal anecdote that leads me to agree with you. During an internship, I fixed some code style issue in a file that I touched for some unrelated reason. The tests had a blind spot just there, and I didn't manually test after the fix, as it was very minor and I couldn't imagine it causing any problems. But it completely broke the feature, and just testing the most basic user scenario would have revealed the screwup. So the bug made it into staging for a 1.5 MAU web application. Fortunately, manual QA caught it early on, so no real damage was done, but while I didn't suffer any serious consequences, people definitely let me know that my actions were irresponsible. That's had a lasting impact on me. I often recall this anecdote when I catch myself thinking "no need to test that, it was a small change", and it's saved my ass a couple of times since. (Of course, better automation is the right way to avoid these kinds of situations, but that's often not attainable in practice due to a number of constraints.)
- gmueckl 9y ago
  I guess every developer has to have that moment of hubris in their career. I remember checking in a seemingly trivial change, telling everybody that it works - only to get told in return that it wouldn't even compile, let alone work when the syntax was fixed! Oops... Sure enough, I became much more cautious after that.
- linuxftw 9y ago
  I don't think your actions were irresponsible. I would assume someone with domain knowledge of the area you changed did a proper code review, especially since you were an intern. If there's not time to write proper tests for code, there's not time for manual testing either. Testing every line of a code change can burn a lot of your time up. Additionally, if a seemingly strange way to do something is necessary for proper function, there should have been a comment in the code to explain why it was doing something in such a particular way.

dh-g 9y ago

Not in the spirit of the project but I would like to see an alias added to the README to replace `git blame` (to run on your own / teammates / friends computers).

jacobevelyn 9y ago
Heh, I actually looked into that but it's not so easy. See: https://stackoverflow.com/a/3538791/1103543 https://stackoverflow.com/a/3538791/1103543 So even if this script is the absolute first thing in your $PATH, `git blame` will always call the builtin rather than this. There are probably more involved ways to make this happen the way you want (like create a different `git` program that shells everything out to the real one except the `blame` command) but I wasn't sure I wanted to go down that rabbit hole. Feel free to submit a PR if you find a simpler way though!
- pcthrowaway 9y ago
  If they're using bash, it shouldn't be so hard. Just put something like this in your/their bashrc git() { if [[ $1 == blame ]]; then shift git self-blame "${@}" else command git "${@}" fi } edit: this isn't 100% perfect as it won't work (but won't break git either) in situations where the user uses a global flag in addition to blame. I've been using git for years though and the only global flag I've used are --version and --help
  - jacobevelyn 9y ago
    Awesome, thanks for sharing! My Bash skills definitely have lots of room for improvement—I think I learned at least three new things from your comment alone. :) I too had never really used global git flags until they came in very handy for `git self-blame`!
sinisterShroom 9y ago
https://github.com/ccraciun/git-blame-bob https://github.com/ccraciun/git-blame-bob Just rename/symlink git-blame-bob to git-blame-joe

throwaway2016a 9y ago

Does this mean we should also have "git self-praise" ?

deleted 9y ago
[deleted]

PricelessValue 9y ago

I'm spartacus!

SilasX 9y ago

Heh, I have a functionally similar joke project that I named git-upstage: https://github.com/SilasX/git-upstage https://github.com/SilasX/git-upstage The difference is, this one's focus is on stealing credit for others' work -- it squashes a branch into one commit under your name, and backdates it five minutes.

dpflan 9y ago
Nice move, preempt this `git-self-blame` tool. Now just make an inverse tool.
- SilasX 9y ago
  Someone submitted "git blame-someone-else" on another thread, where you give someone else the credit for your own commits, and yes I plugged my project on that one too: https://news.ycombinator.com/item?id=11049993 https://news.ycombinator.com/item?id=11049993
jacobevelyn 9y ago
Very cool! I did come across this when I was working on `self-blame` and was (and still am) very impressed!
- SilasX 9y ago
  Thank you!

pimlottc 9y ago

Alternative name suggestion: “git claim”

syntheticcdo 9y ago

I appreciate the time you took to document your journey in the source file. In most github repos, all we see is the end result of hours or days of work (especially when authors blow away their commit history by squashing prior to to sharing), and the comments that explain everything you tried that /didn't/ work are just as illustrative and educational as knowing what does work.

jacobevelyn 9y ago
Thanks, I appreciate the kind words! (And I'm glad at least one person actually read through that.) In this case, I think I was "helped" by the fact that I consider myself relatively inexperienced with both shell scripting and advanced git usage. This gave me an irrational fear that I would publish this repo and get lots of "why didn't you just do X" responses, so writing down my journey was at least one way of showing that I actually tried a few different approaches and while my eventual solution may not be the best I know it's not the worst :)

hinkley 9y ago

Rather than just the author of a line of code, I want git or something git like that allows you to attach commentary to bits of code. For one thing that would allow you to preserve the code reviews but there are bigger reasons for this. In every code base there are at least three generations of styles in the code. The way we want people to write code, the way we used to write it, and the things we wanted the old way to replace. You know, the really terrible code. I find myself from [time] to time wishing I had a way to durably attach commentary to a block of code that doesn’t result in a wall of text and which can’t easily be pruned off in a refactor or a cut and paste. In every team there are people who cut and paste idioms from code they are familiar with into new code. And the code people are [most] familiar with is often the old old way.

jacobevelyn 9y ago
Hey there! This is a really neat idea, and I've been kicking around some semi-similar ideas for a while now but haven't done anything with them. Let me know if you want to bounce around some ideas!