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:<p><a href="https://github.com/SilasX/git-upstage" rel="nofollow">https://github.com/SilasX/git-upstage</a>
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.<p>I wrote a tutorial on a more effective (at least for me) solution to find the true author of a change: <a href="http://blog.andrewray.me/a-better-git-blame/" rel="nofollow">http://blog.andrewray.me/a-better-git-blame/</a>
Should really use "git filter-branch", not "git rebase -i", for automated history modifications. "git rebase -i" is good for interactive usage, not scripting.
This probably could be done using git filter-branch as well.<p>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.<p>[0]: <a href="https://github.com/winks/dotfiles/blob/cfd9d994d0bcd7510203a7e2e6be7260b0d699aa/bin/fakecommit" rel="nofollow">https://github.com/winks/dotfiles/blob/cfd9d994d0bcd7510203a...</a>
Hell, I can do _all_ my work as somebody else with "git config user.name" and "git config user.email".<p>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.
This was also being discussed here [1]<p>[1] <a href="https://news.ycombinator.com/item?id=11049993" rel="nofollow">https://news.ycombinator.com/item?id=11049993</a><p>Apparently it will be obvious to folks that this has occurred.
(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.)<p>I'm tempted to make the observation that there's nothing here you can't already do with a git rebase -i and:<p><pre><code> 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
</code></pre>
But I realize this ability will be novel/surprising to some people, and this is meant to be a joke.<p>I don't do this not because I can't, but because I have no incentive to lie about who wrote/committed certain code.
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.<p>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.<p>now, github being garbage and not accounting for PGP signatures, now this is something else.