91–100 of 185 posts
Even though git -> email link is weak for reasons beyond GitHub's control, I expected email -> github account link to be reliable, since that is entirely under GitHub's control.
I think GitHub is needlessly making a bad situation even worse here.
GitHub’s response is pretty surprising. How can anyone think this is expected? Having to follow Git’s commit message emails makes sense and indeed anybody can use any email they want to make a commit. But then for GitHub to make the connection between (unverified) commit emails and (unverified) GitHub.com accounts is the issue for me. Since they can’t verify the commit email belongs to a GitHub account, why show that…
Because that's git's underlying mechanisms in action. In a distributed system, there's no centralized database to check things against, so there's no (distributed) way to do verification, leading to the issue described here. With the use of public key cryptography, there's a disconnected way to authenticate commit, and it works as well as public key cryptography does, but GitHub has all the levers needed to moved the…
no? git just has an email field on the commit. it's github that has decided to allow people to associate unverified emails with their accounts, and also display this association whereever the email is listed in a commit.
GitHub’s response is pretty surprising. How can anyone think this is expected? Having to follow Git’s commit message emails makes sense and indeed anybody can use any email they want to make a commit. But then for GitHub to make the connection between (unverified) commit emails and (unverified) GitHub.com accounts is the issue for me. Since they can’t verify the commit email belongs to a GitHub account, why show that…
Earlier quoted context omitted.
Really? In this case isn't it just the Github web service that makes a decision on what to display? Sure if you clone the git repo you get the e-mail address, but then you also won't get any information about who the email belongs to on Github. I don't see how the design of Git affects this issue. This is simply one if clause away from being solved in Githubs frontend source code. Just check if email.verified: displa…
Github could easily add its own handling for historical addresses of well-known developers, and block others from masquerading as them, once abuses like this are reported.
Earlier quoted context omitted.
> Still they want the commits to be associated with their current GitHub account Well, tough luck? I don't think it's that important. Just accept it as a fact of life: you lost access to your email account and can't verify you still own it (you don't, clearly). GitHub should just show the e-mail address when it can't associate that to an account, maybe show it's unverified and link to a help page explaining anyone co…
> Well, tough luck? I don't think it's that important. Just accept it as a fact of life: you lost access to your email account and can't verify you still own it (you don't, clearly). This case might not be super important in the long run, but why does it have to be a fact of life? If a system doesn't work as its human operators intend, that's a system failure, not a human being failure.
Neither of these is ideal but at least the second one never tells lies.
Earlier quoted context omitted.
Interesting. One never stops learning new git features... However, while this works for git (i.e., maps old address to new address in "git log" for example), GitHub does not seem to honor this file.
Well, yes, but maybe they should? It doesn't seem like a huge feature...
Earlier quoted context omitted.
> Still they want the commits to be associated with their current GitHub account Well, tough luck? I don't think it's that important. Just accept it as a fact of life: you lost access to your email account and can't verify you still own it (you don't, clearly). GitHub should just show the e-mail address when it can't associate that to an account, maybe show it's unverified and link to a help page explaining anyone co…
> Well, tough luck? I don't think it's that important. Just accept it as a fact of life: you lost access to your email account and can't verify you still own it (you don't, clearly). This case might not be super important in the long run, but why does it have to be a fact of life? If a system doesn't work as its human operators intend, that's a system failure, not a human being failure.
I have used emails in the past I can no longer verify, so I see a use case for linking unverified emails to profiles if there's only one profile claiming the email address However, if another profile verified that email address, it definitely shouldn't link to another profile that hasn't verified
That isn't fair either though. I can see the ISP I quit using 15 years ago letting someone else have my old email address, but now they can claim to be me. I don't know how to handle this situation. It is somewhat easy to verify that a commit today comes from an email address I control now. However if I claim an unverified commit from years back is it really me just because I now control that email?
Earlier quoted context omitted.
In many cases this is the right thing for a maintainer to do: a contributor produces a PR and a proposed patch, but often that patch doesn't solve the whole problem, or clashes with the coding style, or isn't very efficient, so the maintainer does their own fix, because that is faster than getting the contributor to produce a modified version.
The polite thing is to fork the contributor's PR branch back into the project repo, make changes preserving history, and then merge or squash merge the result.
Some projects by nature attract high quality PRs. Others, like a game I built, have the unfortunate curse of attracting PRs with such low quality that it's kinda heart-breaking to shut them down.
It's one thing to read a good feature request in a Github issue and build it yourself. It's a whole other thing to modify a low quality PR in a polite way, see what they were trying to do, clean it up, refactor it. It can easily be 5x the work of just doing it from scratch as the project maintainer.
This experience, especially after your hundredth time, can jade you in a way and make you seem rude when you decide it's not worth the courtesy nor charity.