The author of a commit in git is just metadata. You can set it to whatever you want. This is a necessary feature for distributed workflows, or any kind of workflow where one person may be committing on another person's behalf.
The only way to avoid 'spoofing' commits would be to require them to be signed. Anything else would require a single source of authority on the identity of a given committer, which would defeat the purpose of a distributed VCS.
The OP mentions "security": what's the security issue here? Being able to label a commit as being from defunkt doesn't give you access to anything defunkt has access to.
Except that would make the view of the log look terrible, because there are all kinds of times where the person who pushes is not the person who committed. If 10 people on my team each do a commit on our cool local branch, and I happen to be the one who pushes the branch to git, do all of the changes show up with my name?
What's accurate here? The guys who committed are the guys who are noted as the commit author¹. Just because I pushed the commits to a specific branch of a repo doesn't make me the author of the commit.
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.
Since showing what `git log` actually contains is the definition of 'accurate', I'm not sure what you mean. They aren't "delegated commits", it's the nature of distributed version control: Github's copy of the repo doesn't get to claim special authority over other copies.
I would define accurate as a combination of 'git log' and which account pushed to github. As it is, github seems to treat these commits differently (they aren't showing up on the other users' pages...at least as far as I can tell) so it seems like something that should be indicated in this UI as well.
In a git repo, history is shown with `git log`, so when I ask GitHub to show me the history of the repo, it ought to match `git log`. That's not "non-standard".
But in that case, if I pushed commits from another person (that they sent me over email, for instance) I would end up falsely claiming credit for their work.
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.
Perhaps in situations where the uploading user and the committing user differ, it could read something like "X on behalf of Y". This seems like it would satisfy OP's concerns as well as yours.
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).
This exists in Git and Github accommodates it just fine. See [0] for the following explanation:
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).
The opposite issue is also capable of happening. Don't misunderstand, I completely acknowledge the fact that this is a very difficult issue to solve and fundamental to git design.
I guess it's a UX issue rather than github security, but I could commit as person_X and include in my commit log a message to @person_Y requesting that they take some action (email account details, send bitcoin to an address, etc) which they would only take if they believed the real person_X had asked them to.
It does seem strange that the same visual user identity is associated with an action like creating an issue (requires authentication as user) and creating a commit "by" that user (does not require authentication as user).
I don't think this prevents that requirement from being met -- you can attach a signature to the commit, or keep a separate record of signatures for each commit.
Still would be nice to avoid the duplication though.
Comments
The author of a commit in git is just metadata. You can set it to whatever you want. This is a necessary feature for distributed workflows, or any kind of workflow where one person may be committing on another person's behalf.
The only way to avoid 'spoofing' commits would be to require them to be signed. Anything else would require a single source of authority on the identity of a given committer, which would defeat the purpose of a distributed VCS.
The OP mentions "security": what's the security issue here? Being able to label a commit as being from defunkt doesn't give you access to anything defunkt has access to.
You could just ignore Git metadata and bind it to the account which was used to authenticate (pubkey, pass, etc)
Except that would make the view of the log look terrible, because there are all kinds of times where the person who pushes is not the person who committed. If 10 people on my team each do a commit on our cool local branch, and I happen to be the one who pushes the branch to git, do all of the changes show up with my name?
Maybe the preservation of "delegated commits" is not as important as keeping the commit history accurate?
What's accurate here? The guys who committed are the guys who are noted as the commit author¹. Just because I pushed the commits to a specific branch of a repo doesn't make me the author of the commit.
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.
It could make sense for future versioning systems to separate author from committer.
git supports this:
% 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
Since showing what `git log` actually contains is the definition of 'accurate', I'm not sure what you mean. They aren't "delegated commits", it's the nature of distributed version control: Github's copy of the repo doesn't get to claim special authority over other copies.
I would define accurate as a combination of 'git log' and which account pushed to github. As it is, github seems to treat these commits differently (they aren't showing up on the other users' pages...at least as far as I can tell) so it seems like something that should be indicated in this UI as well.
That's a non-standard definition of the term.
In a git repo, history is shown with `git log`, so when I ask GitHub to show me the history of the repo, it ought to match `git log`. That's not "non-standard".
But in that case, if I pushed commits from another person (that they sent me over email, for instance) I would end up falsely claiming credit for their work.
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.
Perhaps in situations where the uploading user and the committing user differ, it could read something like "X on behalf of Y". This seems like it would satisfy OP's concerns as well as yours.
"Y via X" would be preferable.
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).
This exists in Git and Github accommodates it just fine. See [0] for the following explanation:
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...
The opposite issue is also capable of happening. Don't misunderstand, I completely acknowledge the fact that this is a very difficult issue to solve and fundamental to git design.
I've never had success with passing a rebase around the team, only on a local branch. What's your workflow look like w.r.t. rebasing?
Not only that, but if you push a pre-existing repo to github, you'd lose all information about actual authorship.
I guess it's a UX issue rather than github security, but I could commit as person_X and include in my commit log a message to @person_Y requesting that they take some action (email account details, send bitcoin to an address, etc) which they would only take if they believed the real person_X had asked them to.
It does seem strange that the same visual user identity is associated with an action like creating an issue (requires authentication as user) and creating a commit "by" that user (does not require authentication as user).
I believe PCI compliance requires signed commits. There needs to be proof of who committed each line.
I don't think this prevents that requirement from being met -- you can attach a signature to the commit, or keep a separate record of signatures for each commit.
Still would be nice to avoid the duplication though.