How to take credit for someone else's work on GitHub • Hacker News Board

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

#71

Post by striking » Mon, Feb 28, 2022, 9:02 PM UTC

baobabKoodaa wrote: post #15

striking wrote: post #10

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.

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

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?

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

#72

Post by nixpulvis » Mon, Feb 28, 2022, 9:04 PM UTC

nynyny7 wrote: post #7

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…

What do you want; official Git identities? Sanctioned by Linus himself? Or would you rather log into Xbox Live?

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

#73

Post by trulyme » Mon, Feb 28, 2022, 9:09 PM UTC

nynyny7 wrote: post #38

arraypad wrote: post #27

Earlier quoted context omitted.

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

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

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

#74

Post by greggman3 » Mon, Feb 28, 2022, 9:15 PM UTC

gtirloni wrote: post #41

nynyny7 wrote: post #7

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…

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

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.

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

#75

Post by j3s » Mon, Feb 28, 2022, 9:17 PM UTC

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.

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

#76

Post by kazinator » Mon, Feb 28, 2022, 9:20 PM UTC

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?

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

#77

Post by elderlydoofus » Mon, Feb 28, 2022, 9:21 PM UTC

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.

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.

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

#78

Post by angus-g » Mon, Feb 28, 2022, 9:24 PM UTC

trulyme wrote: post #73

nynyny7 wrote: post #38

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

What about if somebody clones a repo, then adds a .mailmap pointing all the addresses in the history to their own?

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

#79

Post by Arnavion » Mon, Feb 28, 2022, 9:27 PM UTC

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.

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.

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

#80

Post by kangalioo » Mon, Feb 28, 2022, 9:29 PM UTC

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.

On GitHub you can push commits to the PR branch. I use that to fix up rough edges myself and then merge the PR.