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".
Comments
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".