Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to take credit for someone else's work on GitHub

repography.com

Post reply on HN
Print view View original

131–140 of 185 posts

Re: How to take credit for someone else's work on GitHub

#131

Post by saurik »

elderlydoofus wrote: post #77
not2b wrote: post #55

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.

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…

GitHub's "support" for this is the difference between a commit credit and an author credit, which is a mechanism in git that has particular meaning with respect to cherry-picks and rebases. It should be considered awkward to attach someone else as "author" on a commit they might only sort of recognize.

Maybe instead of "taking the time to submit a PR" you should first submit an issue and only work on substantial code changes you are going to become emotionally invested in after you've negotiated the correct path forward with the maintainer? Open source used to be about communication and collaboration, not cowboy coding.

Re: How to take credit for someone else's work on GitHub

#132

Post by jodrellblank »

kelnos wrote: post #106
jodrellblank wrote: post #90

Earlier quoted context omitted.

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.

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 woul…

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

Re: How to take credit for someone else's work on GitHub

#134

Post by Arnavion »

saurik wrote: post #130
Arnavion wrote: post #79

Earlier quoted context omitted.

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 ap…

> 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. While everyone else who uses the project suffers with the bug that was being fixed as they wait for the person who contributed the patch to go through some hazing process involving code formatting that they (hopefully: I realize som…

Well, I wasn't talking about GH OSS repos specifically in that point. In any case, I imagine that any repo that requires signed commits is also corporate-enough that it'll have a CLA requirement, so if the PR author is unresponsive the maintainer could take the code and commit it as themselves anyway.

Re: How to take credit for someone else's work on GitHub

#135

Post by smcameron »

not2b wrote: post #55
elderlydoofus wrote: post #46

Earlier quoted context omitted.

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…

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.

No, not cool. If you modify a submitted commit, set the Author field to the original author and add a Signed-off-by field with your email. Then you BOTH appear.

Re: How to take credit for someone else's work on GitHub

#136

Post by flippinburgers »

bluGill wrote: post #86
myroon5 wrote: post #43

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?

Sign your commits.

Re: How to take credit for someone else's work on GitHub

#137

Post by remram »

Aeolun wrote: post #115
leni536 wrote: post #97

Earlier quoted context omitted.

Now which commit's mailmap file should be used for the association? Whatever is on the "default" branch currently?

Whatever is in the branch you are looking at? Seems fairly straightforward.

Viewing a specific commit or viewing the repositories' statistics ("insights" tab) both have no attached branch.

Re: How to take credit for someone else's work on GitHub

#138

Post by charcircuit »

jreese wrote: post #120
jodrellblank wrote: post #94

Earlier quoted context omitted.

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?

Yes, and there are a number of past stunts that include forking the Linux repo, pushing fake/misleading commits, and then showing how Github lets you see those commits in a context that implies they are part of the upstream Linux repo.

Github now shows a warning when people visit links like that

Re: How to take credit for someone else's work on GitHub

#139

Post by jeroenhd »

kazinator wrote: post #76

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 o…

That wouldn't work, for example, when you're pushing commits someone else did in another repository. Git is decentralized, so you end up pushing a lot of code that you didn't commit if you use it the way it was intended.

The solution, in my opinion, is to show a great big warning or error icon next to the name of every unverified commit, and to every unverified push as well. Developers and version control managers can easily prevent this from happening but few see a reason to sign their commits, and perhaps with a UI change discrediting commits this can change in the future. Setting up signed commits takes five minutes, less if you already have a PGP or S/MIME certificate.

The trick the article shows is a neat trick that will confuse people that don't have any knowledge of how Git works, but the dangers of unconfirmed commits exist go beyond that. A malicious actor could easily inject a backdoor by injecting fake commits impersonating a trusted project member and very few people would be the wiser, unless they actually check the commit manually.

Enterprise/Pro versions of version control software (such as Gitlab) have this feature, but bots exist for free versions as well. You could change CI/CD pipelines to fail if the branch contains unverified commits to hack the functionality into the free version of such systems.

Re: How to take credit for someone else's work on GitHub

#140

Post by Dylan16807 »

jodrellblank wrote: post #132
kelnos wrote: post #106

Earlier quoted context omitted.

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 woul…

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

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

Post reply on HN