[HN Gopher] How to take credit for someone else's work on GitHub
___________________________________________________________________
How to take credit for someone else's work on GitHub
Author : arraypad
Score : 238 points
Date : 2022-02-28 18:25 UTC (4 hours ago)
(HTM) web link (repography.com)
(TXT) w3m dump (repography.com)
| huhtenberg wrote:
| Arpad, your site looks like this -
| https://i.imgur.com/jj9Uxbl.png
|
| Not just the linked page, the homepage too. All but illegible.
| That's in a recent Firefox on Windows. Just FYI.
| arraypad wrote:
| Thanks very much for letting me know, I'll look into that!
| fabianhjr wrote:
| Weird, looks like this for me: https://imgur.com/a/6qL0bWa
| Firefox 97.0.1 Linux version 5.16.11 (gcc 10.3.0, GNU
| Binutils 2.35.2)
| mminer237 wrote:
| I'm on Firefox 97 on Windows 10, and it looks as intended for
| me.
| caslon wrote:
| At some point, we need to start treating Windows like Internet
| Explorer or Safari. Things break on it all the time, completely
| unpredictably, and it doesn't support many useful features
| you'd expect to be used.
|
| We should really just tell Windows users to upgrade to a real
| operating system, rather than go out of our way to support it.
| ______-_-______ wrote:
| I love comparing these kinds of comments to articles like
| this: https://sporks.space/2022/02/27/win32-is-the-stable-
| linux-us...
|
| You really think businesses like Repography should just
| ignore the OS with 80% marketshare?
| [deleted]
| striking wrote:
| This is just a fact of how attribution works in Git. It's not
| GitHub's responsibility to figure out exactly who should be given
| credit for which commit, they're just a viewer on top of Git
| commits.
|
| Imagine you did some work at some workplace years ago, and you
| want credit for it. You don't have access to that email anymore,
| but you'd still like to have the credit and have it link to your
| account. That's the usecase.
| baobabKoodaa wrote:
| > It's not GitHub's responsibility to figure out exactly who
| should be given credit for which commit, they're just a viewer
| on top of Git commits.
|
| If it's not GitHub's responsibility, then why are they doing
| it? Nobody forces GitHub to attribute commits to GitHub user
| accounts. (And yes, you answer this "why" question in your next
| sentence, I'm just pointing out that your argument is
| nonsensical.)
| striking wrote:
| Because they're trying to help build a social graph insofar
| as it helps people do their work, without the aspect of
| actually taking responsibility for being a source of truth
| around it.
|
| Sure, I could claim an original Unix dev's work. But what
| does that actually do, besides raise questions I can't answer
| at interviews?
| j3s wrote:
| how many email addresses can a person associate with their
| account? is there the potential for me to develop a bot that
| scrapes every "unclaimed" email address and claim them? seems
| like a very poor design choice.
| SilasX wrote:
| I remember this earlier subthread where someone was criticizing
| GitHub for allowing this (even using Torvald as someone to
| impersonate!), and others offered some defenses (which were IMHO
| dubious):
|
| https://news.ycombinator.com/item?id=21025378
|
| Also, semi-related, obligatory mention of my joke utility for
| stealing credit for someone else's work:
|
| https://github.com/silasx/git-upstage
|
| Finally, I thought this phrasing was funny, like commits have a
| non-substantively transferable ownership, like an NFT (though FYI
| it's quoting an older discussion of the same problem):
|
| >Someone wrote about the whole situation on Medium in November
| 2021: "The 1st commit of git/git no longer belongs to Linus
| Torvalds".
| anfractuosity wrote:
| What happens if multiple github users add the same unverified
| email address for a particular commit in a repo to their
| accounts, how does it know which github username to pick to
| display next to the commit?
| kazinator wrote:
| In spite of GitHub's claims that nothing wrong, something _is_
| wrong and fixable.
|
| GitHub should be showing the identity pulled from the e-mail
| address, and not replacing it with the name of an associated
| GitHub account. Just like it does when there is no associated GH
| account.
|
| A reasonable compromise would be to show that name, but turn it
| into a link to the account if there is one. Then only someone
| curious clicking on "Linus Torvalds" would see: hey, how come
| this leads to some VanTudor account?
| clutch89 wrote:
| Why does the email address hijacking only work/show up for the
| first commit?
| mynameismon wrote:
| It is not merely for the first commit, here, the first commits
| are used as a proof of concept since they are large repostories
| known to everyone. You can try it yourself, by changing your
| email to something like Linus' email in your git config, and
| then trying to commit code. GitHub will automatically show
| Linus' profile.
| gurjeet wrote:
| I think if the project included a mailmap file [1], supported by
| Git, and if Github honored it, this may not be a problem.
|
| [1]: http://git-scm.com/docs/gitmailmap
| gorkish wrote:
| I'm extremely surprised as well. This seems like a obvious vector
| for an impersonation attack. A malicious user could do this, then
| perhaps they would have more success submitting a malicious
| change to "correct a flaw in their previous commit"
|
| At the very least, repo owners should have some better control
| over how attributions display when the user is not a project
| member or the email used is not verified to an existing user.
| [deleted]
| nyellin wrote:
| Repography looks very cool, but why does it need permission to
| "act on my behalf"?
|
| Is it possible to use without connecting my user at all?
| uncomputation wrote:
| 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 as though it were
| true?
| fragmede wrote:
| 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 needle, with `hub` and them holding public keys for
| registered users.
| INTPenis wrote:
| 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: display
| the user, else, don't do that.
|
| In the else-case all you'd get is a situation where one
| unknown user has Linus e-mail in their list of e-mail
| addresses, in Githubs DB, and a bunch of git commit logs with
| the same e-mail. No one would ever make the connection from
| the commit log to the list of Emails in the DB. Because the
| e-mail hasn't been verified. It's as simple as that to me but
| I could be wrong.
| not2b wrote:
| 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.
| jodrellblank wrote:
| One rule for famous developers, another for all the rest
| of us. Completely backwards because everyone knows Linus
| made Git so that's no threat to him, but someone retro-
| claiming authorship of normal person's work is much worse
| because nobody knows differently. Also expecting Github
| support people to mediate "he said/she said" arguments
| about who made what commits, or owned what email address
| that many years ago.
| nebulous1 wrote:
| > Because that's git's underlying mechanisms in action.
|
| 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.
| berkes wrote:
| And if "the proper way to verify committer identity is, as per
| GitHub's response, a cryptographic signature", Github is
| certainly not pushing this.
|
| If the only real security around attribution is "a
| cryptographic signature", GitHub could do a lot better in
| pushing this, making it essential part of the signup or
| "getting started" and such.
| jodrellblank wrote:
| What happens if Linus Torvalds has a verified Github account,
| and I commit to my rudely named project on my local computer
| with his email address and then push to Github; do they then
| show the commit with his Github account because his Github
| email is verified?
| aledalgrande wrote:
| This is trackable, but I had my PR closed and my contributions
| redressed as another PR a week later by the members of a few
| different prominent opensource projects, without any
| communication on their part. And I only realized by chance.
| leonardinius wrote:
| Dated back to at least 2015
| https://news.ycombinator.com/item?id=10005577
|
| It's old news.
| kevincox wrote:
| Their response is to add a PGP key. But AFAICT they don't do
| verification on PGP keys either. So you could do the same.
| _jal wrote:
| Really? GH Enterprise definitely verifies GPG.
| kevincox wrote:
| It verifies the signature but I was able to just add a public
| key that I found online to my account.
| devrand wrote:
| Will Github verify a commit associated with a GH account
| via an unverified e-mail address?
|
| If so then it's probably fine since you would have to
| demonstrate ownership of an e-mail address that was
| contained in the signed payload, or you would have to be
| able to sign payloads yourself (i.e. you have the private
| key).
| anglinb wrote:
| I worked on the security team at GitHub, this was a long standing
| part of how git works. GitHub allows users to verify commits via
| GPG signatures to prove that they committed something but it
| doesn't work for proving a negative, that you did not commit
| something.
|
| We got so many of these submissions which are clearly called out
| in the rules/scope, usually the people who don't read the rules
| don't find anything useful. -\\_(tsu)_/-
| vgel wrote:
| Obviously anyone can attach any email to any commit, but why
| does the frontend UI work like this:
| gh_profile = get_profile_with_email(commit_email)
|
| and not this? gh_profile =
| get_profile_with_email(commit_email) if not
| gh_profile.has_verified_email_ownership(commit_email):
| return null
| denysvitali wrote:
| I noticed that arraypad is really trying to push his repography
| project. Whilst this is not a bad thing, it seems like he is
| using the blog posts as an excuse to push more his project.
|
| I don't mind that much, but I think I've seen these posts hitting
| the front page quite a lot already - it's a good strategy but it
| could be maybe against the guidelines:
|
| > Please don't use HN primarily for promotion. It's ok to post
| your own stuff occasionally, but the primary use of the site
| should be for curiosity.
| blunte wrote:
| I didn't look at the previous posts you mention, but TFA is
| what I would consider of interest and curiosity. I didn't find
| it at all to be self promotion. You have to read to the bottom
| of the post before you are told what repography is selling.
| tln wrote:
| Personally I think this submission and the other one[1] that
| probably made it to the front page are excellent :)
|
| [1] https://repography.com/blog/go-first-commit
| adewinter wrote:
| A grand total of 7 submissions to blog posts over the course of
| a month is probably fine.
| pornel wrote:
| I knew about the ability to push commits as someone else, but
| GitHub allowing taking ownership of other people's commits in
| their own repos, using an _unverified_ e-mail address seems like
| a whole another level of insecurity here.
|
| 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.
| myroon5 wrote:
| 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
| bluGill wrote:
| 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?
| totony wrote:
| What does it matter if someone can claim your commits?
| Doesn't seem important imo.
| i_have_an_idea wrote:
| The author seems to have little to no understanding on how git
| or, really, any distributed system without a centralized or
| blockchain database works. Yes, this is the intended behavior and
| it is not up to Git (or even GitHub) to verify the identity of
| commits. Of course, you can do that in your organization, if you
| want, by requiring signing commits with GPG but it makes no sense
| that something like this would be baked into a DCVS.
|
| After given what I believe is a pretty comprehensive explanation
| on how git works from GitHub staff, the author continues to
| pretend that this is somehow a security issue that should be
| awarded a bounty. Not to mention this behavior has been reported
| many times in the past, including this exact example -- in 2015.
| Ridiculous.
| peeters wrote:
| I think you're missing the point of what the author is asking.
| Showing the email address from the commit is one thing (and the
| author is fine with showing that). That's the limit to what git
| gives you. Associating that email address to a GitHub user
| profile _which never verified ownership of that email address_
| is a GitHub UX decision, having nothing to do with git. That 's
| what the author is saying is a security flaw.
|
| That said, clearly users _shouldn 't_ be ascribing any level of
| certainty to commits that point to a GitHub profile _even if
| the email address is verified_ , since AFAIK nothing is
| stopping the inverse attack, i.e. having someone else take
| credit for _your_ work. Which is arguably more exploitable.
| jokethrowaway wrote:
| That's not the main complain, the issue is that GitHub is
| allowing users to claim emails even without verifying users are
| the owners of those emails.
| i_have_an_idea wrote:
| how are they claiming emails?
| peeters wrote:
| > The problem is that GitHub makes this association even
| for unverified email addresses. In this case of course it
| really was Linus who made the first commit, but all it took
| was someone to add Linus's email address to their GitHub
| profile - without any verification - and now GitHub
| displays this person as the author instead.
| i_have_an_idea wrote:
| I can also write on my own web site that my email address
| is linus@linuxfoundation.org. But I can't send or receive
| messages from it, so how exactly would I be _claiming_
| it?
|
| Does GitHub allow you to impersonate Linus via email? No,
| it does not.
| peeters wrote:
| I think you're fixated on the inverse of what this is.
| Imagine it's a true commit by Linus identified by his
| email address. This issue is when someone creates a
| GitHub profile with Linus' email address and by doing so,
| causes the GitHub UI to ascribe authorship of that commit
| to your user profile via your GitHub username and a link
| to your profile.
| moritzwarhier wrote:
| I'm not entirely sold on the explanation "This is just how git
| commit (messages) work". GitHub could easily limit linking the
| GitHub profile to profiles whose e-mail address has been verified
| (by usual means, no GPG required).
|
| They could show statistics and attribution limited to the data
| available in the commit messages (e.g. accumulated statistics by
| e-mail address) for contributors without a GitHub profile.
|
| Am I missing something here? (Edit: just read the other comments
| addressing the use cases)
| a-dub wrote:
| so this is obviously an ad for this repography thing, which looks
| pretty cool.
|
| so.. does it do anything interesting with stuff like git blame
| -CCC which shows the genealogy of copypasta across time within a
| repo?
| whateveracct wrote:
| Sign your commits if you care about this!
|
| iirc, isn't signing with the same ssh key you push with a
| possibility?
| guptarohit wrote:
| for these reasons I have started using PGP signing for commits
| and releases I make
| anandoza wrote:
| Could someone also write bad code and commit it using someone
| else's email address in the commit message, thus making the
| commit link to the other person's Github profile? (Sort of the
| reverse problem -- "giving blame" instead of "taking credit")
| skeaker wrote:
| Now you're thinking like the author of git-blame-someone-else:
| https://github.com/jayphelps/git-blame-someone-else
| TrianguloY wrote:
| Yes, simply change the email and author before commit and
| should work.
|
| Note that git already provides a way to mark a commit with
| someone else authorship, but in that case you remain as the
| "original author" of the commit, usually shown as "X authored
| commit of Y". I sometimes use that when I need to push other
| coworkers code for whatever reason, or when you start a
| codebase from an old project files that weren't versioned (so
| that you are not the author of all the atrocities of the old
| code ;)
| klabb3 wrote:
| Yes, but it isn't limited to non-verified emails, you can do it
| with verified emails as well. I assume it's already used to
| obscure deliberate security compromises in forks etc.
|
| There are many practical impersonation vectors. I assume Github
| is gonna have to require signed commits for profile links in
| the medium term future.
| TrianguloY wrote:
| Why not add a small orange (!) icon next to the name for
| unverified emails, or a similar indicator? As a way of saying
| "this user claimed authorship, but we couldn't verify it".
|
| When you commit from the Github page itself, a similar green
| "verified" check is shown, but if you do it from command line and
| then push nothing is shown. So the infrastructure for special
| verifications messages is there, and perhaps could be used.
| roblabla wrote:
| It's possible to show the "verified" check when commiting from
| the command line, you just have to sign the commit with a PGP
| key, and associate said PGP key with your account on github.
| TrianguloY wrote:
| I supposed that, but wasn't sure. Thanks for the
| confirmation!
| rockbruno wrote:
| 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 wrote:
| but pushing commits with other authors is a really common thing
| in many git workflows.
| MereInterest wrote:
| That 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 wrote:
| > 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.
| lowercased wrote:
| I thought this might be something different. Have seen this
| happen multiple times over the years - even once just last week.
|
| Colleague files an issue with a PR. Project owners close it, say
| 'no, not a bug', then... commits the same thing themselves as
| "fixed!". Saw this years before in cvs/svn, and... at least in
| the GH world there's some evidence of the original PR author
| having done the work in the first place (vs being invisibly cut
| out).
| jamjamjamjamjam wrote:
| The owner of huey does this. He closes PRs and submits the code
| himself
| elderlydoofus wrote:
| I had this happen on a small PR I submitted within the past
| year. I didn't think anything of it at the time, but your
| comment led me to glancing through the past PRs and it's
| comical how many are closed with a "thanks, I've committed an
| equivalent patch" comment.
|
| One the one hand, it's his repo and he's free to do whatever
| he wants. I actually admire how ruthless the maintainer is on
| closing issues, must be great for staving off OSS burnout.
|
| On the other hand, I don't love how antagonistic it is to
| outside contributors. Litestream[0] is an example of open
| source-closed contributions, but at least it's upfront about
| that in the README. (And the policy has actually changed to
| open for bug fixes.) I would open an issue/PR on Huey
| suggesting adding a similar disclaimer, but it'd probably be
| closed, ha.
|
| [0] https://github.com/benbjohnson/litestream#contribution-
| polic...
| not2b wrote:
| 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.
| scatters wrote:
| 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.
| hombre_fatal wrote:
| It is a bit awkward though.
|
| 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.
| elderlydoofus wrote:
| Yeah, I get why this happens. And to be clear, I didn't
| dig in to the all the PRs and compare them vs the
| maintainer's commits, so I have no idea of the difference
| in code quality between the two.
|
| I'm sure it's frustrating when maintaining a fairly
| popular OSS tool to receive a PR that's 95% of the way
| there. Having to go back and forth to coach someone on
| getting that last 5% (or the contributor just dropping
| the PR then ghosting) vs just doing it yourself, I
| totally get it.
|
| However from the contributor's point of view, when GH has
| support for co-authored commits, it comes of as a bit of
| jerky move when you take the time to submit a PR to not
| at least get credit via a co-author commit message.
| Arnavion wrote:
| Yes, I do this for my own OSS projects. The standard
| approach of giving feedback and waiting for the user to
| fix something is fine, but for a small change it's easier
| to just expedite the process and do it myself.
|
| But if my version of the code has substantial changes (ie
| changes beyond just whitespace, small tweaks to the code,
| changing the commit message), I push it to a branch and
| ask the PR author to review and approve it first. Only
| after they approve it do I merge it into master and close
| the PR.
|
| I also retain the GIT_AUTHOR of the original PR so that
| they still get credit; my user is only the GIT_COMMITTER.
| And I add a "Closes #" ref to the GH PR in the commit
| message so that it can be tracked later. git also has a
| de-facto standard of having multiple authors for a commit
| via `Co-authored-by:` lines in the commit message. This
| is useful for when my contribution is large enough to be
| equivalent to the PR author's.
|
| Note that this doesn't work for workflows that require
| signed commits. If you have such a workflow, you have to
| go back to giving feedback and waiting for the PR author
| to make changes.
| kangalioo wrote:
| On GitHub you can push commits to the PR branch. I use
| that to fix up rough edges myself and then merge the PR.
| lowercased wrote:
| it _can_ be, yes. there 's chicken and egg issue of
| trying to help other people be more proficient in making
| those mods, learning about larger parts of the system,
| etc.
|
| there's also the issue of being told "no, that's not a
| bug" or "no, WONTFIX", then... hours or days later...
| producing the same code patch as your own. Definitely a
| jerk move.
| quickthrower2 wrote:
| Because Git/Github is source control tool not a forensic tool.
| FlacoJones wrote:
| One thing to note: I believe this only works if the email is not
| already associated with a GH account.
| nfoz wrote:
| Veering off topic but I absolutely hate that git requires you to
| have an "email address" (which cannot be empty and iirc must
| satisfy some regex criteria for a valid-looking address). A
| particular choice of user identifier or communication medium
| should not be hardcoded into the totally unrelated concern of
| source-control, IMO. Anonymous and non-email accounts should be
| first-class things. Instead of email maybe you'd want to have
| your public-key or something.
| Bayart wrote:
| AFAIK git was made with an email workflow in mind. Git's the
| byproduct on the Linux kernel project, for better or worse.
| GitHub provide a fake email address that's tied to your GH
| account for commit stats, which is an appreciated utility.
| marwis wrote:
| Nothing is stopping you from using anonymous@localhost or
| YOUR_KEY_ID@publickey
| zestyping wrote:
| An obvious and feasible improvement is to least make it clear in
| the UI which addresses are verified or unverified.
| nynyny7 wrote:
| I do see a point in it working like it does, though. I'm one of
| the lead developers on a free software project with over 20 years
| of history. Even though the project has used multiple version
| control systems (and hosting providers) over time, we have
| imported our entire project's history going back to the very
| first commit into git and GitHub.
|
| Not every contributor has kept their email address for over 20
| years. Some don't have access to the old addresses they once used
| for commits. Still they want the commits to be associated with
| their current GitHub account; even if it's just for statistics
| and "bragging rights".
|
| If GitHub required email address verification, how would this be
| done?
|
| EDIT: To be clear: With "working like it does" I'm referring to
| the possibility to add unverified email addresses to your account
| and have commits attributed to you.
| odyssey7 wrote:
| One idea: just show the statistics of unverified commits,
| demarcated as such, in the user's profile. This is a more
| transparent variation on the current behavior.
| baobabKoodaa wrote:
| > If GitHub required email address verification, how would this
| be done?
|
| You could just run a script which rewrites the email address in
| all the git commits, and force-push the revised version.
| giancarlostoro wrote:
| Does this redo all the commit hashes?
| nynyny7 wrote:
| Yes, as it is rewriting history. And that would be a
| massively bad idea.
| progval wrote:
| Given that GGP's use case is:
|
| > we have imported our entire project's history going back
| to the very first commit into git
|
| Then it isn't a problem. Just change the email addresses
| while importing.
| nixpulvis wrote:
| What do you want; official Git identities? Sanctioned by Linus
| himself? Or would you rather log into Xbox Live?
| gtirloni wrote:
| _> 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 could have faked that in
| the commit. I don't understand why they care so much to put a
| face (the GH account) on the commit when the address is not
| verified.
| greggman3 wrote:
| Maybe github should use gravatar if the email doesn't match a
| github account. Not that that helps with old email address
| you no longer control but it does let you add an image to an
| arbitrary email you do control, separate from github.
| np- wrote:
| > 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.
| Gigachad wrote:
| Because we exist in the real world with real constraints.
| We have only two options, allow people to stick their name
| on others commits, or have unverified emails just show
| plainly.
|
| Neither of these is ideal but at least the second one never
| tells lies.
| charcircuit wrote:
| You could add humans into the verification process. I
| imagine the number of people who want to associate old
| emails they don't have access to with accounts to be small.
| If you could prove that you owned the account via other
| means it could be manually added to your profile.
| d23 wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| arraypad wrote:
| In this case I think you could use a .mailmap [1] in the repo
| to associate the old email addresses with current, verified
| addresses.
|
| [1] https://git-scm.com/docs/gitmailmap
| nynyny7 wrote:
| 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.
| Kwpolska wrote:
| GitHub bases the association of commits to user accounts on
| the list of e-mail addresses configured in the user's
| profile: https://github.com/settings/emails
| trulyme wrote:
| Well, yes, but maybe they should? It doesn't seem like a
| huge feature...
| leni536 wrote:
| Now which commit's mailmap file should be used for the
| association? Whatever is on the "default" branch
| currently?
| angus-g wrote:
| What about if somebody clones a repo, then adds a
| .mailmap pointing all the addresses in the history to
| their own?
| trulyme wrote:
| If somebody clones the repo they can even rewrite
| history. But that is not the same as them being able to
| claim the ownership of a commit in the _original_ repo.
___________________________________________________________________
(page generated 2022-02-28 23:00 UTC)