8 ms·

Git Blame-Someone-Else

225 points by dcminter 7y ago

SilasX 7y ago
Obligatory self-promotion of my opposite joke project, git-upstage, which steals credit for someone else's work. (Squashes their branch to a single commit under your name and backdates it five minutes.) https://github.com/SilasX/git-upstage https://github.com/SilasX/git-upstage (Inspired by the time someone typo'd "unstage" to "upstage" and I guessed what a git-upstage command would be.)
jay_kyburz 7y ago
This will come in handy when the Australian Government compels a programmer to put a backdoor in their companies software.
saagarjha 7y ago
Personally, I find this really useful when I accidentally squash something incorrectly during a rebase and in the process of cleaning it up end up with changes attributed to the “wrong” person.
- spraak 7y ago
  Check out `git reflog` to go back to before the mistake
- deleted 7y ago
  [deleted]
mohsen0 7y ago
And that is why signing commits should be enforced.
- Znafon 7y ago
  You would already get a conflict as the history of the repo changed and signing all commits as some drawbacks as Torvalds explained here: http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-t... I'm not sure it's better.
  - inlined 7y ago
    I think Torvald’s stance is reasonable when considering a customer’s safety as guaranteed by an organization. E.g. this build is signed as safe. Commit signatures are useful in large organizations designed to worry about insider threats. If code that is reckless or malicious is found in a build, you want repudiation of the author. Lack of commit signatures allows a malicious actor to cover their tracks. And also, we should accept that we don’t treat all authors with the same scrutiny. Veterans’ code gets scrutinized less, so let’s actually trust that they’re the real author before signing a tag with their code.
    - hinkley 7y ago
      How would merges work there? I've had a coworker, "Tom", who was terrible with three way merges (why is it the people awful at merges want to do the most merges by insisting on feature branches for their code?) I'm still not sure what he was doing but some of his merges ended up with the wrong name next to code. We started figuring this out about him when "George" was getting dressed down for a bug he introduced. Two things drew me into this. First, I was getting tired of things being blamed on George. Everybody in this group had issues, nobody should have been pointing fingers at anybody else, especially this guy or his partner in crime, Tom. But equally important to me at that moment was that I was the primary on that code review, so now it's on me too. A lot of code I look at becomes a bit of a blur, but I remembered this block of code particularly well, because it was the sort of tricky code that George sometimes cocks up but bless him if he didn't get it right on the first try. Only the code we were upset about wasn't the code I reviewed. His name was on it. The commit sequence lined up. What the hell. An excruciatingly long git bisect later (git bisect is not built for some things, this included) and I track it down to a bad three way merge by Tom. He ended up with some bastardized version of left and right that had its own set of bugs, and George's name on the commit. I hadn't known you could do that with Git. It was quite upsetting.
      - tomcatfish 7y ago
        Do you have any more information of any kind on this (like info you have run into since then)? This sounds very interesting and it also sounds like something I should be aware is possible to do (especially on accident).
p4bl0 7y ago
It's funny but it doesn't actually work because the hash of the modified commit and all subsequent ones will necessarily change, right? So it would be very visible to everyone that a change has been made as it might break a lot of things to force-push an incompatible history of commit.
- kbumsik 7y ago
  > it doesn't actually work because the hash of the modified commit and all subsequent ones will necessarily change, right? True, so it is just a joke.
- dcminter 7y ago
  Although your point is perfectly valid, I don't think the tool is intended for anything other than fun.
- alex_duf 7y ago
  The following hashes do changes (you can see that on the gif on their readme). I think you're meant to force push after using the tool
warpech 7y ago
What is more, you can: 1. clone https://github.com/torvalds/linux https://github.com/torvalds/linux into https://github.com/<YOURNAME>/linux https://github.com/<YOURNAME>/linux. 2. push a fake "torvalds" commit into your repo. 3. check the SHA of the the commit that you made. 4. the commit will be visible at the original repo URL with your SHA (https://github.com/torvalds/linux/commit/<SHA> https://github.com/torvalds/linux/commit/<SHA>), with no indication whatsoever that this is coming from a different repo I have reported this problem to GitHub a while ago and they replied to me that this is a well known feature of the repo "network".
- jimktrains2 7y ago
  I've never really understood Torvalds' reason for not cryptographiclly signing commits. > Btw, there's a final reason, and probably the really real one. Signing each commit is totally stupid. It just means that you automate it, and you make the signature worth less. It also doesn't add any real value, since the way the git DAG-chain of SHA1's work, you only ever need _one_ signature to make all the commits reachable from that one be effectively covered by that one. So signing each commit is simply missing the point. http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-t...
  - Aperocky 7y ago
    Oh, I've had that at one of the place I used to work at. The git commit tree is signed, and once a team member left no one can create branches any more because all of his commits are now insecure. Yeah that was fun.
  - Roritharr 7y ago
    I guess he's of the school that it doesn't matter who commits the code, it needs to be checked anyway, for bugs or being malicious.
  - utopian3 7y ago
    Unless I am missing something, his point seems to be different. He doesn’t seem to care about the non-repudiation of a user
danilocesar 7y ago
isn't this just a wrap on top of git rebase -i HASH^; git commit --amend --author "Jhon Doe"? Also, as already noted, this overwrites all the history after the commit, making it useless. Then people said it's a joke... I know I will get downvoted for this comment, but How did this make to the first page of HN?
- b88d80170 7y ago
  agree. same question here.
- SamuelAdams 7y ago
  [deleted]
- pferde 7y ago
  It's Friday, some levity is acceptable here and there.
  - danilocesar 7y ago
    =) Sounds fair.
jacobevelyn 7y ago
A few years ago I made a similar project with a slightly different twist: https://github.com/JacobEvelyn/git-self-blame https://github.com/JacobEvelyn/git-self-blame I did it as a learning exercise, and if anyone's interested I documented the source in a lot of detail to show everything I learned along the way.[1] [1] https://github.com/JacobEvelyn/git-self-blame/blob/master/git-self-blame https://github.com/JacobEvelyn/git-self-blame/blob/master/gi...
brlewis 7y ago
This might have a serious use. I have a private repo that I worked on with my daughter. If I open source it, ideally I'd keep the chronological history but scrub her email address out of it. It's OK that all the commit hashes would change. Would I want to adapt this joke tool to that purpose, or is there an exiting tool for rewriting history that way?
- i_v 7y ago
  GitHub also supports a special <username>@users.noreply.github.com address if you wanted her to retain semi-anonymous authorship as a GitHub user.
  - brlewis 7y ago
    The repo is on gitlab, but I can always make up a noreply address.
- klodolph 7y ago
  The standard way to do that is with 'git filter-branch'. If your daughter’s email is megatron@example.com, git filter-branch --env-filter ' old_email=megatron@example.com new_email=redacted if [ "$GIT_COMMITTER_EMAIL" = "$old_email" ] ; then export GIT_COMMITTER_EMAIL="$new_email" fi if [ "$GIT_AUTHOR_EMAIL" = "$old_email" ] ; then export GIT_AUTHOR_EMAIL="$new_email" fi ' -- --all This is “safe” in the sense that you can go back to the old version with the reflog if you screw things up.
  - saidajigumi 7y ago
    Seconded. The git blame-someone-else tool is just using git rebase and git commit --amend internally to alter one specified commit. git filter-branch is perfect for this kind of wholesale revision. filter-branch is essential for tasks like: open-sourcing repos that need some kind of cleanup, massaging repos generated by a VCS migration tool, etc. For example, years ago I participated in the move of a large CVS repo to git; there was significant filter-branch post-processing required to create an acceptable baseline)
some1else 7y ago
Mine is https://github.com/some1else https://github.com/some1else
eljimmy 7y ago
I really dislike the term chosen for this feature. “Blame”, assumes the code is broken or written improperly in some way. Most of the time I use it I’m just trying to find out who wrote it so I can find the original commit to understand it in more context. Should have named it “git who”
- brantonb 7y ago
  Xcode 10 changed their per-line annotation feature from Blame to Authors.
- panda88888 7y ago
  Or “git credit”
  - deleted 7y ago
    [deleted]
- thwarted 7y ago
  You can always use "git annotate" or alias git commands in your gitconfig.
- AceJohnny2 7y ago
  SVN has the alias "svn praise". I was disappointed that git didn't have it, so I created myself one. I'm glad git has trivial support for aliases.
  - chemodax 7y ago
    AFAIK original was "cvs annotate" [1]. Subversion introduced "svn blame" and "svn praise" aliases for "svn annotate" as some kind of joke. It's funny that git only has "git blame". [1] https://compbio.soe.ucsc.edu/cvsdoc/cvs-manual/cvs_74.html https://compbio.soe.ucsc.edu/cvsdoc/cvs-manual/cvs_74.html
- ElijahLynn 7y ago
  Also, `git tell` the story.
xivzgrev 7y ago
Loool

225 points by dcminter 7y ago

Obligatory self-promotion of my opposite joke project, git-upstage, which steals credit for someone else's work. (Squashes their branch to a single commit under your name and backdates it five minutes.) https://github.com/SilasX/git-upstage https://github.com/SilasX/git-upstage (Inspired by the time someone typo'd "unstage" to "upstage" and I guessed what a git-upstage command would be.)

jay_kyburz 7y ago

This will come in handy when the Australian Government compels a programmer to put a backdoor in their companies software.

saagarjha 7y ago

Personally, I find this really useful when I accidentally squash something incorrectly during a rebase and in the process of cleaning it up end up with changes attributed to the “wrong” person.

spraak 7y ago
Check out `git reflog` to go back to before the mistake
deleted 7y ago
[deleted]

mohsen0 7y ago

And that is why signing commits should be enforced.

Znafon 7y ago
You would already get a conflict as the history of the repo changed and signing all commits as some drawbacks as Torvalds explained here: http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-t... I'm not sure it's better.
- inlined 7y ago
  I think Torvald’s stance is reasonable when considering a customer’s safety as guaranteed by an organization. E.g. this build is signed as safe. Commit signatures are useful in large organizations designed to worry about insider threats. If code that is reckless or malicious is found in a build, you want repudiation of the author. Lack of commit signatures allows a malicious actor to cover their tracks. And also, we should accept that we don’t treat all authors with the same scrutiny. Veterans’ code gets scrutinized less, so let’s actually trust that they’re the real author before signing a tag with their code.
  - hinkley 7y ago
    How would merges work there? I've had a coworker, "Tom", who was terrible with three way merges (why is it the people awful at merges want to do the most merges by insisting on feature branches for their code?) I'm still not sure what he was doing but some of his merges ended up with the wrong name next to code. We started figuring this out about him when "George" was getting dressed down for a bug he introduced. Two things drew me into this. First, I was getting tired of things being blamed on George. Everybody in this group had issues, nobody should have been pointing fingers at anybody else, especially this guy or his partner in crime, Tom. But equally important to me at that moment was that I was the primary on that code review, so now it's on me too. A lot of code I look at becomes a bit of a blur, but I remembered this block of code particularly well, because it was the sort of tricky code that George sometimes cocks up but bless him if he didn't get it right on the first try. Only the code we were upset about wasn't the code I reviewed. His name was on it. The commit sequence lined up. What the hell. An excruciatingly long git bisect later (git bisect is not built for some things, this included) and I track it down to a bad three way merge by Tom. He ended up with some bastardized version of left and right that had its own set of bugs, and George's name on the commit. I hadn't known you could do that with Git. It was quite upsetting.
    - tomcatfish 7y ago
      Do you have any more information of any kind on this (like info you have run into since then)? This sounds very interesting and it also sounds like something I should be aware is possible to do (especially on accident).

p4bl0 7y ago

It's funny but it doesn't actually work because the hash of the modified commit and all subsequent ones will necessarily change, right? So it would be very visible to everyone that a change has been made as it might break a lot of things to force-push an incompatible history of commit.

kbumsik 7y ago
> it doesn't actually work because the hash of the modified commit and all subsequent ones will necessarily change, right? True, so it is just a joke.
dcminter 7y ago
Although your point is perfectly valid, I don't think the tool is intended for anything other than fun.
alex_duf 7y ago
The following hashes do changes (you can see that on the gif on their readme). I think you're meant to force push after using the tool

warpech 7y ago

What is more, you can: 1. clone https://github.com/torvalds/linux https://github.com/torvalds/linux into https://github.com/<YOURNAME>/linux https://github.com/<YOURNAME>/linux. 2. push a fake "torvalds" commit into your repo. 3. check the SHA of the the commit that you made. 4. the commit will be visible at the original repo URL with your SHA (https://github.com/torvalds/linux/commit/<SHA> https://github.com/torvalds/linux/commit/<SHA>), with no indication whatsoever that this is coming from a different repo I have reported this problem to GitHub a while ago and they replied to me that this is a well known feature of the repo "network".

jimktrains2 7y ago
I've never really understood Torvalds' reason for not cryptographiclly signing commits. > Btw, there's a final reason, and probably the really real one. Signing each commit is totally stupid. It just means that you automate it, and you make the signature worth less. It also doesn't add any real value, since the way the git DAG-chain of SHA1's work, you only ever need _one_ signature to make all the commits reachable from that one be effectively covered by that one. So signing each commit is simply missing the point. http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-t...
- Aperocky 7y ago
  Oh, I've had that at one of the place I used to work at. The git commit tree is signed, and once a team member left no one can create branches any more because all of his commits are now insecure. Yeah that was fun.
- Roritharr 7y ago
  I guess he's of the school that it doesn't matter who commits the code, it needs to be checked anyway, for bugs or being malicious.
- utopian3 7y ago
  Unless I am missing something, his point seems to be different. He doesn’t seem to care about the non-repudiation of a user

danilocesar 7y ago

isn't this just a wrap on top of git rebase -i HASH^; git commit --amend --author "Jhon Doe"? Also, as already noted, this overwrites all the history after the commit, making it useless. Then people said it's a joke... I know I will get downvoted for this comment, but How did this make to the first page of HN?

b88d80170 7y ago
agree. same question here.
SamuelAdams 7y ago
[deleted]
pferde 7y ago
It's Friday, some levity is acceptable here and there.
- danilocesar 7y ago
  =) Sounds fair.

jacobevelyn 7y ago

A few years ago I made a similar project with a slightly different twist: https://github.com/JacobEvelyn/git-self-blame https://github.com/JacobEvelyn/git-self-blame I did it as a learning exercise, and if anyone's interested I documented the source in a lot of detail to show everything I learned along the way.[1] [1] https://github.com/JacobEvelyn/git-self-blame/blob/master/git-self-blame https://github.com/JacobEvelyn/git-self-blame/blob/master/gi...

brlewis 7y ago

This might have a serious use. I have a private repo that I worked on with my daughter. If I open source it, ideally I'd keep the chronological history but scrub her email address out of it. It's OK that all the commit hashes would change. Would I want to adapt this joke tool to that purpose, or is there an exiting tool for rewriting history that way?

i_v 7y ago
GitHub also supports a special <username>@users.noreply.github.com address if you wanted her to retain semi-anonymous authorship as a GitHub user.
- brlewis 7y ago
  The repo is on gitlab, but I can always make up a noreply address.
klodolph 7y ago
The standard way to do that is with 'git filter-branch'. If your daughter’s email is megatron@example.com, git filter-branch --env-filter ' old_email=megatron@example.com new_email=redacted if [ "$GIT_COMMITTER_EMAIL" = "$old_email" ] ; then export GIT_COMMITTER_EMAIL="$new_email" fi if [ "$GIT_AUTHOR_EMAIL" = "$old_email" ] ; then export GIT_AUTHOR_EMAIL="$new_email" fi ' -- --all This is “safe” in the sense that you can go back to the old version with the reflog if you screw things up.
- saidajigumi 7y ago
  Seconded. The git blame-someone-else tool is just using git rebase and git commit --amend internally to alter one specified commit. git filter-branch is perfect for this kind of wholesale revision. filter-branch is essential for tasks like: open-sourcing repos that need some kind of cleanup, massaging repos generated by a VCS migration tool, etc. For example, years ago I participated in the move of a large CVS repo to git; there was significant filter-branch post-processing required to create an acceptable baseline)

some1else 7y ago

Mine is https://github.com/some1else https://github.com/some1else

eljimmy 7y ago

I really dislike the term chosen for this feature. “Blame”, assumes the code is broken or written improperly in some way. Most of the time I use it I’m just trying to find out who wrote it so I can find the original commit to understand it in more context. Should have named it “git who”

brantonb 7y ago
Xcode 10 changed their per-line annotation feature from Blame to Authors.
panda88888 7y ago
Or “git credit”
- deleted 7y ago
  [deleted]
thwarted 7y ago
You can always use "git annotate" or alias git commands in your gitconfig.
AceJohnny2 7y ago
SVN has the alias "svn praise". I was disappointed that git didn't have it, so I created myself one. I'm glad git has trivial support for aliases.
- chemodax 7y ago
  AFAIK original was "cvs annotate" [1]. Subversion introduced "svn blame" and "svn praise" aliases for "svn annotate" as some kind of joke. It's funny that git only has "git blame". [1] https://compbio.soe.ucsc.edu/cvsdoc/cvs-manual/cvs_74.html https://compbio.soe.ucsc.edu/cvsdoc/cvs-manual/cvs_74.html
ElijahLynn 7y ago
Also, `git tell` the story.

xivzgrev 7y ago

Loool