
Show HN: git self-blame – Blame yourself for others' mistakes - jacobevelyn
https://github.com/JacobEvelyn/git-self-blame
======
gedaxiang
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.

~~~
gmueckl
I used svn blame a lot recently, but never to trace the cause of bugs. I break
out the usual tools (debugger and brains) for that. I only resort to blame to
understand how a particular odd piece of code came to be (e.g. commented out
leftovers that were last touched years ago and forgotten). Even then, I mostly
need to see how line changes relate and when they were made. The author is
merely a reference of last resort - a pointer to a person who might, with some
luck, still remember that he worked on that part.

When I find a bug in code that a colleague has written I simply tell him about
my changes to it. That keeps him in the loop and gives me a confirmation that
my attempted fix should indeed be OK. Of course, in more formal projects,
tickets and code reviews would replace that process.

Blame is not about assigning blame. The feature has a terrible name because it
brings up this undesired association. It is about understanding the lineage of
the code.

~~~
darrenf
> _The feature has a terrible name_

But in svn the feature is actually called "annotate"; "blame" and "praise" are
mere aliases for it. To quote the book[0]:

    
    
        you may find yourself typing svn blame …
        or svn praise … instead of using the canonical
        svn annotate command form. That's okay—the
        Subversion developers anticipated as much,
        so those particular command aliases work, too!
    

[0] [http://svnbook.red-
bean.com/en/1.7/svn.tour.history.html#svn...](http://svnbook.red-
bean.com/en/1.7/svn.tour.history.html#svn.tour.history.browsing.annotate)

~~~
gmueckl
Without looking at the archives, I believe that annotate and praise were
introduced well after the initial implementation which used blame as the
command. I may be wrong, though.

~~~
darrenf
It seems the command is listed as `blame` even in the v1.0 book, but does even
then have the `annotate` and `praise` aliases. In all the years I used svn I
firmly believed annotate was the canonical form and it was the one I always
used, so I've learnt something here (about svn, and maybe about myself).

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

~~~
jacobevelyn
Very cool! I did come across this when I was working on `self-blame` and was
(and still am) very impressed!

~~~
SilasX
Thank you!

------
jacobevelyn
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/gi...](https://github.com/JacobEvelyn/git-self-
blame/blob/master/git-self-blame)

------
hinkley
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
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!

------
dh-g
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
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
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
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`!

------
syntheticcdo
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
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 :)

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

~~~
chhs
Or only the names of people who no longer work at the company

~~~
AntonyGarand
I suggest making a git blame-nemesis for this purpose

~~~
iamdave
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.

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

------
pimlottc
Alternative name suggestion: “git claim”

