[HN Gopher] Git-blame-someone-else
___________________________________________________________________
Git-blame-someone-else
Author : swyx
Score : 141 points
Date : 2021-07-26 19:08 UTC (3 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| rossmohax wrote:
| `git replace` does it without rebasing, which is cleaner and
| likely to be left unnoticed by peers.
| Hokusai wrote:
| 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.
| jarofgreen wrote:
| 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 :-)
| ornornor wrote:
| 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.
| Ashanmaril wrote:
| 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
| deadbunny wrote:
| 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.
| david_allison wrote:
| You can fix this! Look into the "ignore revs" file option on
| git blame or the option: blame.ignoreRevsFile
|
| https://git-scm.com/docs/git-blame#Documentation/git-blame.t...
| thanksforfish wrote:
| 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.
| ornornor wrote:
| 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.
| imoverclocked wrote:
| 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...
| Hokusai wrote:
| That was our problem. We added a git hook to reject new
| malformed commits. The easier way to not mess more things
| was to make all the code base compliant.
| praptak wrote:
| That's common. Most tools like Magit make it easy to dig down
| through multiple layers of formats, renames, refactors and typo
| fixes to find the commit that actually introduced something.
|
| It's usually called "blame previous revision".
| er4hn wrote:
| I'm going to use this as an example of why commit signing is
| really awesome for git repos.
| consp wrote:
| This somehow reminds me of how svn blame/praise was the same
| command.
| 40four wrote:
| This is hilarious! Got a good laugh from this. It also
| illustrates how easy it is to impersonate other people in Git.
| I'm surprised this isn't discussed more.
|
| To be honest, when you really think about it, any commit that is
| not GPG signed is unverifiable. It could be anybody. I wish
| signing commits was more widespread.
| DougBTX wrote:
| I was expecting this to be like `git blame`, but to automatically
| check previous revisions for any lines touched by the current
| user. That would be a fun toy :-)
| ffjffsfr wrote:
| 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.
| jb1991 wrote:
| 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.
| pixl97 wrote:
| I'll be keeping an eye on this account. I feel in a few months
| JB will be promoted to manager.
| birdyrooster wrote:
| Now that's a straight shooter with upper management written
| all over him.
| ornornor wrote:
| 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?)
| iandinwoodie wrote:
| I think he is joking. I hope he is joking.
| MeinBlutIstBlau wrote:
| As someone else is saying, its obviously a joke. Even a
| halfway intelligent person would be able to create an alibi
| that they didnt do it.
| bostonsre wrote:
| Could be good for resume padding. O yea, I wrote 75% of linux...
| dylan604 wrote:
| I've worked with that dev. After 2 weeks on the job, you
| realize the resume was full of shit, and are actively looking
| at ways to replace that dev.
| cratermoon wrote:
| 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?
| mb7733 wrote:
| 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.
| rzzzt wrote:
| Re: the introductory animation, NASA has .gov adresses, it is not
| a commercial entity. With that said, sign your commits!
| ggregoire wrote:
| Still need to be able to "push --force" on the remote repo for
| this to be useful, right?
| mcobzarenco wrote:
| if you're not already enforcing signed commits, you deserve it
| cantsingh wrote:
| aka 'git gaslight'
| Lapsa wrote:
| useful tool. I like it
| brianpursley wrote:
| 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...
| MeinBlutIstBlau wrote:
| So gonna use this to game my gihub account honestly. At least
| it can make saying "I'm a team player" much easier.
| nkozyra wrote:
| Oh man. I was thinking they'd probably patch that but ... how
| could they?
| albertgoeswoof wrote:
| Only show contributions with GPG signed commits
| easton wrote:
| And if you want to do this for something before the code is
| written: https://github.com/jmathai/all-hands-on-deck
| rwmj wrote:
| 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 :-)
| lifthrasiir wrote:
| Missed opportunity: append random whitespace characters to all
| subsequent commits so that the first N characters of commit id
| are retained.
| cantsingh wrote:
| combine this with Lucky Commit
| shhsshs wrote:
| This is a great example of why you should enable vigilant mode
| [1] on your GitHub account and set your machine up to GPG sign
| your commits.
|
| [1] https://docs.github.com/en/github/authenticating-to-
| github/m...
| teitoklien wrote:
| But if you gpg sign your commit Now all your contributors will
| have to sign their next commits too.
|
| My workmates would hate me if i introduced this to production.
| rsstack wrote:
| I am the only person on my team who signs their commits. No
| one complained or noticed.
| dang wrote:
| Others were to blame for past threads:
|
| _Git Blame-Someone-Else_ -
| https://news.ycombinator.com/item?id=21004193 - Sept 2019 (66
| comments)
|
| _Git-blame-someone-else - Blame someone else for your bad code_
| - https://news.ycombinator.com/item?id=11049993 - Feb 2016 (65
| comments)
| infogulch wrote:
| Does it feel like gardening? Moderating HN that is. It'd have
| to be one of those "wild gardens" that's mostly the plants
| doing what they want with a bit of nudging. Pull out a weed
| here, tie up some branches there, clear the path, give a little
| extra water to something that didn't get a good chance yet,
| etc. Sorry for the OT, I was just curious if that analogy
| resonated.
| glxxyz wrote:
| git commit --amend --author=[...]
| rwmj wrote:
| Which is almost exactly how this works:
| https://github.com/jayphelps/git-blame-someone-else/blob/8d8...
| stevebmark wrote:
| Stop using git blame to look up who authored code, it's not a
| useful tool. Use git log -S <string> 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.
| nicoburns wrote:
| 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.
| Icathian wrote:
| Gitlens extension in vscode is quite good for this as well
| ffjffsfr wrote:
| 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
| DannyBee wrote:
| 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 figure out what someone _actually_ changed, trying to turn
| applesauce back into apples.
|
| Whether it gets it right or not has an element of luck to it
| (the diff algorithms are also often based on finding the
| minimal sequence of edits.). Whether it happens depends on
| the algorithm and it's heuristics, and often whether there is
| a single unique minimal sequences that could produce your end
| state from your beginning state (if not, it's not actually
| possible to say what you changed with 100% accuracy)
|
| git log -S instead is saying "give me all the times this line
| seems to have changed", and then you do the work of figuring
| out which were real and which are artifacts of the diff
| algorithm.
| emodendroket wrote:
| It doesn't have to be that detailed or bullet-proof to be
| good enough for like 90% of cases.
| DannyBee wrote:
| I actually don't have a strong opinion, i'm just
| responding to the comment about why they suggest what
| they suggest.
| cerved wrote:
| it depends on the code base but I get your sentiment
| dasil003 wrote:
| 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.
___________________________________________________________________
(page generated 2021-07-26 23:00 UTC)