
Git-blame-someone-else – Blame someone else for your bad code - mablae
https://github.com/jayphelps/git-blame-someone-else
======
SilasX
Should probably use this moment to plug my (opposite) project, git-upstage,
which lets you claim credit for someone else's work and backdate it so it
looks like you did it first:

[https://github.com/SilasX/git-upstage](https://github.com/SilasX/git-upstage)

~~~
0x4a42
Much better. Love the hacker's twist. :)

------
andrewray
It's been my experience, especially in the startup scene where business
requirements change often, that `git blame` rarely shows you what you want.
Files get renamed, moved, re-indented, etc, frequently.

I wrote a tutorial on a more effective (at least for me) solution to find the
true author of a change: [http://blog.andrewray.me/a-better-git-
blame/](http://blog.andrewray.me/a-better-git-blame/)

~~~
versteegen
Nice tutorial, but aren't you aware that "git blame -w" ignores whitespace
changes? git blame also always follows renames. git's rename detection isn't
foolproof (if I edit and rename A.cpp to A-star.cpp at the same time as adding
a new A.cpp file it won't detect it), however there are two more blame options
for that: -C to follow lines copied between files, and -M to follow lines
moved within a file.

Unfortunately, adding -M and -C will quite badly increases the time to compute
the blame. Both take an adjustable parameter (min number of characters to
match), but I found I actually had to reduce it to catch all the lines in an
example of the A.cpp -> A-star.cpp move I did yesterday.

~~~
sadgit
I would love to be able to use left and right to skip quickly through
revisions when viewing a blame, do you know anything for that?

~~~
versteegen
That's something I've wanted for a long time too.

tig (a curses-based git interface) fits the bill, though it can be quite
confusing (too many keybindings). "tig blame -w <file>" to view a blame (-w to
ignore whitespace), and then you can press , on a line to recompute the blame
using the parent of that commit, while moving to the ancestor of that line
(but tracking the line frequently doesn't work). And < to go back to the
previous commit.

I remember that tortoisesvn was fairly nice for viewing blames, IIRC you can
move through history inside it with some clicking around, and the tortoisegit
interface appears to be largely the same:
[https://tortoisegit.org/docs/tortoisegit/tgit-dug-
blame.html](https://tortoisegit.org/docs/tortoisegit/tgit-dug-blame.html)
Windows only however.

------
lambda
Should really use "git filter-branch", not "git rebase -i", for automated
history modifications. "git rebase -i" is good for interactive usage, not
scripting.

------
andrewstuart2
And this is why I pgp sign all my commits. :-P

~~~
exDM69
It's a bit worrying that GitHub will happily associate someone's face on a
commit that they didn't write: [https://github.com/jayphelps/git-blame-
someone-else/commit/e...](https://github.com/jayphelps/git-blame-someone-
else/commit/e5cfe4bb2190a2ae406d5f0b8f49c32ac0f01cd7)

Perhaps GitHub should only do this for signed commits or commits to the
author's own repository or something.

GitHub also allows you to add anyone to a project without their consent (or
has this changed?). This reminds me of the Facebook prank where someone added
Mark Zuckerberg to a fake(?) pro-paedophile group.

~~~
andrewstuart2
Agreed.

It should be trivial for them to allow you to paste your pgp public key as you
would your ssh public key, then place a nice little "verified" check mark next
to commits that can be validated as having been signed with one of your
associated private keys.

~~~
mbrock
There are so many things that GitHub could easily do, but don't... Makes me
wonder what they actually do.

~~~
tinco
You mean besides developing and operating one of the best services on the web?

~~~
SilasX
Best in what sense? Bitbucket does everything Github does, plus gives free
private repos. GitHub is just more widely used.

~~~
stepvhen
Bitbucket crashes minimal browsers like Surf and github doesn't. So, in that
regard, Github is better.

~~~
DHowett
It seems odd to blame BitBucket and not Surf for this.

------
wink
This probably could be done using git filter-branch as well.

Not rewriting history, I still have this little script called fakecommit[0]
lying around I have used in the past to commit stuff under other people's
names.

[0]:
[https://github.com/winks/dotfiles/blob/cfd9d994d0bcd7510203a...](https://github.com/winks/dotfiles/blob/cfd9d994d0bcd7510203a7e2e6be7260b0d699aa/bin/fakecommit)

------
32bitkid
Hell, I can do _all_ my work as somebody else with "git config user.name" and
"git config user.email".

If that's really a genuine concern, then a) you are working with a big bag of
dicks and b) there are _way_ worse things that person can do with write access
to the repository than masquerade as somebody else.

~~~
newday
As stated in the project read me, it's just a joke project.

~~~
32bitkid
No, I get it, but even in this thread there is a higher-than-expected amount
of hand-wringing.

~~~
logicallee
I totally agree with 32bitkid's view of the other comments, makes a good
point.

------
LinuxBender
This was also being discussed here [1]

[1]
[https://news.ycombinator.com/item?id=11049993](https://news.ycombinator.com/item?id=11049993)

Apparently it will be obvious to folks that this has occurred.

~~~
manojlds
Um, mostly no. This can be trivially detected only when you are changing
things already pushed.

Being a dvcs, you create atleast one commit on your local repo before pushing
to a remote. That one (or more) commit can be changed to point at anyone and
pushed.

~~~
asabjorn
Mostly yes. You rewrite the whole history from the commit you changed authors
on and onwards so git will let you know that you have two conflicting
histories that needs to be merged. This is why the author needs to force push
to master.

The only exception to this is if someone else has not pulled into their
private repo any changes at or before the commit you changed.

~~~
manojlds
What I am saying is that this tool can be used exclusively while creating
commits. Not for retroactive changes.

------
cevaris
Hey Bob, what is up with the `git push --force master`?

------
LinuxBender
This is a good example of why git repos should be snapshot and archived to
read-only media periodically.

I like this! Thank you

~~~
detaro
It does a rebase, so everybody that has a copy and pulls will notice.

~~~
LinuxBender
Good point. Would code review tools catch this? Gerrit, Crucible, et al? More
specifically, how obvious would it be and would people question what they see?

~~~
detaro
Tools will probably show that you are trying to merge/push all commits since
(and including) the changed one, unless they have something special to detect
rebases and display them differently.

------
jayphelps
Here's the tweet:
[https://twitter.com/_jayphelps/status/695782397439139840](https://twitter.com/_jayphelps/status/695782397439139840)

------
shurcooL
(When I saw the title, I was wondering if this does something beyond the basic
rebase, like trying to brute force a commit such that all following commits
are preserved (hash doesn't change), but that's essentially impossible.)

I'm tempted to make the observation that there's nothing here you can't
already do with a git rebase -i and:

    
    
        GIT_COMMITTER_NAME=a GIT_COMMITTER_EMAIL=a@a.com GIT_COMMITTER_DATE=2006-01-02T15:04:05Z git commit --author='a <a@a.com>' --date 2006-01-02T15:04:05Z
    

But I realize this ability will be novel/surprising to some people, and this
is meant to be a joke.

I don't do this not because I can't, but because I have no incentive to lie
about who wrote/committed certain code.

~~~
infinity0
> all following commits are preserved (hash doesn't change), but that's
> essentially impossible.

Actually, you only need _one_ brute-force (of the commit that you're
changing); subsequent commits only refer to the parent hash, and here we're
not changing the commit trees either.

SHA1 is already considered broken, so git really should switch to SHA256 soon.
This whole "sha1 commit hashes are not for security" argument is mostly naive
and bogus.

The only way it would be safe, is if (a) everyone set their GPG to default to
SHA256 or above (older versions still default to SHA1) and (b) either (b.1)
everyone signed every commit this way, or (b.2) everyone signed their tags
this way _and_ just before tagging, reviewed their local commits including
commits not authored by them up to the previously trusted tag.

But if git defaulted to SHA256 or SHA512, then we wouldn't have to reason
through the complex scenarios involving (b). Making something "too secure" is
a good thing if it simplifies your security analysis and allows you to use
your head for other productive things.

~~~
gre
Why SHA-256 instead of SHA-3?

~~~
infinity0
No particular reason, I just picked that as the default choice in my head.
SHA-3 also works, just less widely implemented atm. (Still waiting for a
sha3sum command in coreutils).

------
_jomo
Previously on HN:
[https://news.ycombinator.com/item?id=10005577](https://news.ycombinator.com/item?id=10005577)

------
mjklin
$ git push SEP-field

------
gcb0
what's the point? you just rebased with a incompatible tree. nobody will be
able to update that because their trees will say the commit differs.

and in the only case this would work, i.e. nobody has that commit yet, you
could just have commited as that person. nothing new or interesting.

now, github being garbage and not accounting for PGP signatures, now this is
something else.

