6 ms·

> 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

> 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)

djur 12y ago
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.
- gluxon 12y ago
  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.
- shawnz 12y ago
  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.
  - djur 12y ago
    "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).
  - arjie 12y ago
    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). [0] http://git-scm.com/book/en/Git-Basics-Viewing-the-Commit-History http://git-scm.com/book/en/Git-Basics-Viewing-the-Commit-His...
- couchand 12y ago
  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?
- jfrisby 12y ago
  Not only that, but if you push a pre-existing repo to github, you'd lose all information about actual authorship.
akerl_ 12y ago
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?
- SilasX 12y ago
  Maybe the preservation of "delegated commits" is not as important as keeping the commit history accurate?
  - akerl_ 12y ago
    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.
    - jaredsohn 12y ago
      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.
    - SilasX 12y ago
      >Since showing what `git log` actually contains is the definition of 'accurate', That's a non-standard definition of the term.
      - akerl_ 12y ago
        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".

> 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)

djur 12y ago

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.

gluxon 12y ago
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.
shawnz 12y ago
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.
- djur 12y ago
  "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).
- arjie 12y ago
  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). [0] http://git-scm.com/book/en/Git-Basics-Viewing-the-Commit-History http://git-scm.com/book/en/Git-Basics-Viewing-the-Commit-His...
couchand 12y ago
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?
jfrisby 12y ago
Not only that, but if you push a pre-existing repo to github, you'd lose all information about actual authorship.

akerl_ 12y ago

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?

SilasX 12y ago
Maybe the preservation of "delegated commits" is not as important as keeping the commit history accurate?
- akerl_ 12y ago
  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.
  - jaredsohn 12y ago
    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.
  - SilasX 12y ago
    >Since showing what `git log` actually contains is the definition of 'accurate', That's a non-standard definition of the term.
    - akerl_ 12y ago
      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".