4 ms·

> This case might not be super important in the long run, but why does it have to be a fact of life? For the very reason mentioned in this article: people can

by d23 5y ago

> This case might not be super important in the long run, but why does it have to be a fact of life? For the very reason mentioned in this article: people can claim the commits without verification.

jodrellblank 5y ago
Why doesn't the fact of life go the other way? "people can claim the commits without verification." - Well, tough luck? I don't think it's that important. Just accept it as a fact of life. You didn't cryptographically sign your commit and now nobody (including you) can prove who made it.
- kreetx 5y ago
  I think the issue is that this isn't a "fact of life", so github could either show the original email or pull in the account with a verified email. What it does now appears to be a bug.
- kelnos 5y ago
  The distinction is in where the potential harm can be. With the current status quo (unverified email addresses can "steal" commits), you create confusion in the general developer community. Anyone who looks at those mis-attributed commits will be confused, and possibly misled. If GH didn't associate commits unless the email address was verified, then, yes, some people wouldn't get "bragging rights", but the harm would be limited to that person. Others who look at those commits would still see the correct person's name, even though it wouldn't be associated with a particular GH account.
  - jodrellblank 5y ago
    > "Others who look at those commits would still see the correct person's name," They would see the name which was written into the commit; assuming that's "the correct person" is the same mistake. Associating to the GitHub verified email account is incorrect in the same fashion, but going the other way. They're both only text saying "Linus Torvalds", in the absence of signing, neither is more or less authoritative than the other. Connecting it to a random profile looks wrong, but trying to correct it to the 'right' profile lends it an air of legitimacy it shouldn't have. Papering over that is like teaching people to click through warning messages, or that HTTP is fine because the site shows the right looking text.
    - Dylan16807 5y ago
      > Papering over that is like teaching people to click through warning messages, or that HTTP is fine because the site shows the right looking text. That's a completely separate problem, and whether it is papered over is completely independent of this problem. With this problem, even if you already verified the repo, even if there are signatures, it still shows the wrong profile. > Connecting it to a random profile looks wrong, but trying to correct it to the 'right' profile lends it an air of legitimacy it shouldn't have. Displaying nothing is not "trying to correct it to the 'right' profile"

by d23 5y ago

> This case might not be super important in the long run, but why does it have to be a fact of life? For the very reason mentioned in this article: people can claim the commits without verification.

jodrellblank 5y ago

Why doesn't the fact of life go the other way? "people can claim the commits without verification." - Well, tough luck? I don't think it's that important. Just accept it as a fact of life. You didn't cryptographically sign your commit and now nobody (including you) can prove who made it.

kreetx 5y ago
I think the issue is that this isn't a "fact of life", so github could either show the original email or pull in the account with a verified email. What it does now appears to be a bug.
kelnos 5y ago
The distinction is in where the potential harm can be. With the current status quo (unverified email addresses can "steal" commits), you create confusion in the general developer community. Anyone who looks at those mis-attributed commits will be confused, and possibly misled. If GH didn't associate commits unless the email address was verified, then, yes, some people wouldn't get "bragging rights", but the harm would be limited to that person. Others who look at those commits would still see the correct person's name, even though it wouldn't be associated with a particular GH account.
- jodrellblank 5y ago
  > "Others who look at those commits would still see the correct person's name," They would see the name which was written into the commit; assuming that's "the correct person" is the same mistake. Associating to the GitHub verified email account is incorrect in the same fashion, but going the other way. They're both only text saying "Linus Torvalds", in the absence of signing, neither is more or less authoritative than the other. Connecting it to a random profile looks wrong, but trying to correct it to the 'right' profile lends it an air of legitimacy it shouldn't have. Papering over that is like teaching people to click through warning messages, or that HTTP is fine because the site shows the right looking text.
  - Dylan16807 5y ago
    > Papering over that is like teaching people to click through warning messages, or that HTTP is fine because the site shows the right looking text. That's a completely separate problem, and whether it is papered over is completely independent of this problem. With this problem, even if you already verified the repo, even if there are signatures, it still shows the wrong profile. > Connecting it to a random profile looks wrong, but trying to correct it to the 'right' profile lends it an air of legitimacy it shouldn't have. Displaying nothing is not "trying to correct it to the 'right' profile"