> The only way to avoid 'spoofing' commits would be to require them to be signed.
You could just ignore Git metadata and bind it to the account which was used to authenticate (pubkey, pass, etc)
You could just ignore Git metadata and bind it to the account which was used to authenticate (pubkey, pass, etc)
That's a non-standard definition of the term.
Also, imagine the following:
1. Alice writes some code and pushes it to a feature branch. She does not necessarily use github, though she does use git.
2. Bob pulls from Alice's feature branch into a new feature branch. He then pushes to his own repo on github. All commits are rewritten to have Bob as the author.
3. Charlie pulls from Alice's feature branch into a new feature branch. He then pushes to his own repo on github. All commits are rewritten to have Charlie as the author.
4. If we go and bind it to the account, then suddenly everyone's history diverges. Bob and Charlie certainly see different histories. The fact that Alice is the one who actually wrote these commits is completely lost.
I mean, it doesn't even make sense in a common-sense way. Why do I become the 'author' if I just pushed the code to a specific place? If you want to have some chain, force a merge commit every time someone merges.
¹ Well, specifically, they're the commit's committer, but if they did the work, they're the author too. Everything still applies.
% git config --get user.name
Original Committer
% git commit -m "Test" --author "Test Dude <test@example.com>"
% git log -n 1 --pretty="%cn, %an: %s"
Original Committer, Test Dude: Test
This would also be a huge issue for rebase workflows, because rebasing changes the commit SHA. Every commit I rebased would end up belonging to me, not the original author.
It's worth keeping in mind that what GitHub does now is what _every_ other git client does, and it's in GitHub's best interest not to confuse users (or to make it look like they're privileging a GitHub-based workflow over a standard git workflow).
> You may be wondering what the difference is between author and committer. The author is the person who originally wrote the patch, whereas the committer is the person who last applied the patch. So, if you send in a patch to a project and one of the core members applies the patch, both of you get credit — you as the author and the core member as the committer.
Try it by setting the author on a commit you make. Github displays it just fine. I used to use it in school when working with non-comp-sci students on collaborative work (for instance, a report written in LaTeX).
[0] http://git-scm.com/book/en/Git-Basics-Viewing-the-Commit-His...