Live data from Hacker News

Git-blame-someone-else

github.com

41–50 of 100 posts

Re: Git-blame-someone-else

#42

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.

git blame and git log -S are both granular tools with their own blindspots. To actually get to the bottom of something you need a higher level tool which lets you iterate through historical changes across multiple files over time. The workflow is 1) git blame problematic area 2) open full commit + diff for that change so you can see context 3) open relevant file(s) as they existed in that commit 4) repeat steps 1,2 and 3 until you get to root cause.

This workflow is not subject to any limitations around code structure, variable naming, file moving or anything else. fugitive.vim is a plugin which lets you very quickly recurse into history in this fashion using multiple vim windows.

Re: Git-blame-someone-else

#44
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.

At one company I did a project that among other things involved bringing in a code formatter. I deliberately tagged that commit with a generic author :-)

Haha, I did that too because most of our code is just so shitty I didn’t want the shame of it looking like I was the author.

Re: Git-blame-someone-else

#45
post #33

It’s not just blame. GitHub uses commits to build the contributor list on your repo home page, so you can make it look like it has some famous contributors: https://github.com/jayphelps/git-blame-someone-else/graphs/c...

Oh man. I was thinking they'd probably patch that but ... how could they?

Only show contributions with GPG signed commits

Re: Git-blame-someone-else

#46
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.

Ran into this issue where contributors editors were reformatting the whole file they touched based on the newly created code formatting config file. Some editors would pick it up and automatically reformat on save so a commit with 3 actual lines changed looked like 90% of the file had changed in the diff. So we went with the nuclear option and did one massive PR that reformatted the whole codebase.

Re: Git-blame-someone-else

#47
post #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.

Curious how do you get away with it without anyone noticing. Doesn’t this imply rewriting the master branch? Wouldn’t that cause noticeable issues for everyone else? Or maybe you’re the only active contributor on that codebase (but then who else can you blame?)

Re: Git-blame-someone-else

#48

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, an…

Well for one thing, the unscrupulous employee would need to have force push permissions to the origin repo.

Even if they they did, once they change the history change, other developers working with the repo would be alerted of the remote branch changing out from under them next time they try to pull. And even if the change doesn't result in a conflict, and each of those other devs blindly accept the resulting merge, the original authors' commits will still be in the history resulting from the merge. So if those developers ever pushed anything, the original commits would be re-introduced.

Now, it could be abused if a single developer inherits a project that nobody else has checked out. But it's still a high risk strategy for the unscrupulous dev.

Re: Git-blame-someone-else

#49
post #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.

Curious how do you get away with it without anyone noticing. Doesn’t this imply rewriting the master branch? Wouldn’t that cause noticeable issues for everyone else? Or maybe you’re the only active contributor on that codebase (but then who else can you blame?)

I think he is joking. I hope he is joking.

Re: Git-blame-someone-else

#50

Earlier quoted context omitted.

how is git log -S more efficient? You have to write whole line, what if line is long? What if you need to look at several lines within some range. git blame is much better than your git log -S

git blame can't possibly work well in all cases, which is why the author is saying that. Git doesn't store what actually was changed. Git stores how to reconstruct the new file from the old file in a space efficient way. This is unrelated to storage of who changed what, only "what is the minimal way to reproduce the end state from the beginning state". As a result, tools like blame take the two versions and try to fi…

It doesn't have to be that detailed or bullet-proof to be good enough for like 90% of cases.
Post reply on HN