Live data from Hacker News

Git-blame-someone-else

github.com

21–30 of 100 posts

Re: Git-blame-someone-else

#23
post #2

The commit hash of the blamed commit and all ones after that change, so the system works. One day we may be able to reliably/easily generate SHA-1 collisions to really get someone else to take the blame :-)

Missed opportunity: append random whitespace characters to all subsequent commits so that the first N characters of commit id are retained.

combine this with Lucky Commit

Re: Git-blame-someone-else

#24

Stop using git blame to look up who authored code, it's not a useful tool. Use git log -S to search for changes to that line (then repeat with the previous version of that line, until you find the original author), and/or git log -L to track changes to a code block. Don't waste your time with git blame.

My editor (sublime text) has built in git blame support. It's literally right-click -> blame file, and it will put the author of every line in the margin.

Gitlens extension in vscode is quite good for this as well

Re: Git-blame-someone-else

#25
post #7

I runned a code formatter in our code base. Years later I was still 'blamed' for many things in our code as few files were untouched.

We recently converted our monolith codebase at work from windows-1252 encoding to UTF-8 and now the entire project looks like it was written by 1 guy

I can't remember the command off the top of my head (on mobile) but you can exclude specific commits from things like blame for situations like this.

Re: Git-blame-someone-else

#27
post #7

I runned a code formatter in our code base. Years later I was still 'blamed' for many things in our code as few files were untouched.

I think it's best to migrate to a preferred formatting slowly, versus touching everything at once. I've had open pull requests that I've started over due to aggressive reformatting like that. Between that and breaking tools like 'git blame', it can be painful.

This approach sometimes works for formatting but the issue with ad-hoc approaches is finding ways of enforcing on new commits. This is especially so with a large developer base.

Once you move on from just banal issues like whitespace and move your way up to actual structural concepts in the code, ad-hoc starts completely falling apart (at least in my experience.)

I once encountered someone who did a giant re-formatting of code by rewriting past commits. Pretty disruptive for a day but did manage to keep history in-tact. Also, a little (or a lot?) dangerous...

Re: Git-blame-someone-else

#28

Could be good for resume padding. O yea, I wrote 75% of linux...

This thought occurred to me, too. The example given is about pinning bad code on someone else, but the inverse is also possible: changing the author of good code to yourself. I'm kind of wondering, now, if there are some unscrupulous coders out there messing with their employer's internal git repos to give themselves credit for work other people did. I knew one guy who would create tickets, assign them to himself, and then abuse the tickets closed metric to inflate his productivity claims. He wasn't very subtle about it, either. Of course management ought to have been more skeptical of that, but .. stuff happens.

Yeah, I work in information security for a living, how did you guess?

Re: Git-blame-someone-else

#29
it runs git rebase under the hood, in production environment with multiple people pushing to repo it will break things and it'll be spotted immediately. So this actually shows how hard it is to spoof commit author, you can't do it without leaving a trace, git is a solid system.

Re: Git-blame-someone-else

#30
This has saved me so many times. I’m sure I would have lost my job a while ago had I not been able to use this, it’s one of my most actively use tools. I’m sure eventually I’ll be losing my job, but at least this repo has enabled me to keep it a little bit longer.
Post reply on HN