3 ms·
It seems that one proper solution could be: 1 - Don't associate the commit to an account if the email is unverified, obviously 2 - If someone tries to "forge"
by rockbruno 5y ago
It seems that one proper solution could be:
1 - Don't associate the commit to an account if the email is unverified, obviously
2 - If someone tries to "forge" ownership by pushing a commit with an e-mail that doesn't belong to the GitHub account being used to push, a "unverified" warning should be added to the commit and manually claimed by the account owning said e-mail for its status to change.
- detaro 5y agobut pushing commits with other authors is a really common thing in many git workflows.
- MereInterest 5y agoThat would break any workflow that has the slightest bit of decentralization, and would only work in a github-first workflow. Suppose two developers are working on a feature that requires two changes. Each developer works on a change in their own development branch. It wouldn't make sense to submit a PR for each change, because they depend on each other to be a complete feature. Therefore, they should merge the two dev branches together, then submit a pull request for that merged development branch to then be merged into the main branch. In your proposed scheme, this would then show up as an attempted forgery, rather than a perfectly normal workflow. The email field is for humans, who can lie, and shouldn't be used as authoritative by github.
- nebulous1 5y ago> this would then show up as an attempted forgery, rather than a perfectly normal workflow. they said unverified, not marked as a forgery > The email field is for humans, who can lie, and shouldn't be used as authoritative by github. and your solution is just to have everything marked as unverified, including commits that I push using my credentials and contain an email that I've verified with github.