4 ms·

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 workf

by djur 12y ago

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.

iancarroll 12y ago
> 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".
JaggedJax 12y ago
I believe PCI compliance requires signed commits. There needs to be proof of who committed each line.
- SilasX 12y ago
  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.
Myrmornis 12y ago
> what's the security issue here? 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).

by djur 12y ago

iancarroll 12y ago

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

JaggedJax 12y ago

I believe PCI compliance requires signed commits. There needs to be proof of who committed each line.

SilasX 12y ago
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.

Myrmornis 12y ago

> what's the security issue here? 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).