46

I'm not a programmer by profession, but I do some coding and have used github some. I've run across what I find to be a surprising situation. I'm very familiar with git.

There is a project which I found a (small) bug in that was affecting me. I spent an afternoon finding and fixing it. I forked the repository, commit the change, and issued a pull request. After seeing that it was closed as "Merged into development branch" I figured all was well.

I was browsing the repo today getting ready to remove my branch, and I can't find where the commit was merged into the maintainer's repo at all. After some time I realize it's been added as a commit, but the author is no longer me.

As far as I can tell the only way to do that would be to specifically use a rebase, amend, or other history rewrite to remove the original author.

This seems very wrong to me. At best it's confusing, at worst the author of this repo is taking credit for everyone's commits and then the history of the original contributor is lost. Again it's a small bug, I don't use this for my professional resume, it just seems dishonest.

Is this normal? Should I say something about it?

Edit: The general feeling seems to be that I should go ask, so I'll do just that this morning.

As per the request below. I've checked and my code exists and was applied exactaly as I wrote it (including the comment). I verified that both the committer and author have been changed. There was one additional change also added at the same time as my changes. It's a single line, which would affect the patch as well as other code before it. IE the one line addition is not related to the bug I was fixing.

Update It seems the answer was that the author maintains a development branch and does not want to merge from his master branch into it. He re-authored my commit to avoid a merge. I wasn't concerned with the original branch b/c git's plenty powerful to cherry-pick, rebase, and merge commits around as needed.

Is this typical on github?
Should I be contacting the maintainer of a project to ask which branch to apply patches to?

Improve this question
6
  • 8
    +1 for raising an ethical question about coding :) Interested in finding out if this is the default behavior, seems like a bit of extra work for the maintainer to do this. Or would this happen if the maintainer modified your commit slightly after accepting your pull request?
    – Sunil D.
    Aug 8, 2012 at 18:03
  • That's a good question. I'm not familial enough with github to answer what's normal. However, I do think it's possible to cherry-pick with the -n option, make modifications, and then commit. Effectively changing the author.
    – user1585512
    Aug 8, 2012 at 18:12
  • 4
    Perhaps the maintainer applied your change manually rather than merging it. I suggest asking the maintainer about it (without accusing him/her of dishonesty).
    – Keith Thompson
    Aug 8, 2012 at 18:20
  • 6
    Just to be clear, it's the "author" that's changed, correct? Not the "committer"? I only ask because the distinction is extremely important when it comes to the ethics of code plagerism.
    – Christopher
    Aug 8, 2012 at 18:34
  • 2
    You don't say how large the fix was (lines of code) or how the code is licenced but, arguably, this could also be an infringement of your copyright.
    – Jaydee
    Aug 10, 2012 at 13:19

5 Answers 5

Reset to default
24

No they shouldn't, if avoidable. It's a problem that in my experience happens far too often. However I believe it is more to do with ignorance of how to use git correctly than somebody wanting to steal credit.

  • If they want to modify your change before applying it to their main branch, they can easily create a branch for your change. They can then add their own commit after yours and then merge the branch in.
  • If your pull request is not based on the latest version of their main branch, then they can issue a git rebase master. If there are conflicts they can either choose to fix the conflicts themselves (without changing author), or give you the chance to fix it.

I think Github could and should look for this kind of accidental credit stealing and educate maintainers on best practices when appropriate.

Improve this answer
6

You have left out some key details here.

  • If the way you "fixed" the bug was not to the maintainers liking, or even incorrect in that it introduced its own bugs, then the maintainer might have had to edit your work before committing. In which case it is understandable to change the author.

  • As others have mentioned the author is quite different from the committer. As you may already know the author is the one who actually created the commit, while the committer would be the one to apply it.

You should take a close look at the commit and update your question with your findings.

Improve this answer
1
  • 2
    I did just go check this. There are no changes to my patch. There was a 1-line change before and not related to my patch that was added at the same time.
    – user1585512
    Aug 10, 2012 at 12:33
3

It seems the answer was that the author maintains a development branch and does not want to merge from his master branch into it. He re-authored my commit to avoid a merge.

Improve this answer
1
  • 14
    Then they should have used git cherry-pick.
    – svick
    Jan 26, 2013 at 17:33
3

To answer your updated question:

It is hard to say what is typical on github, beyond saying that typically every project is different and each has their own preferred workflow. Generally the best approach before sending a pull request is to ask what their workflow is or try to see if you can tell based off previous closed pull requests.

My personal experience has been if you do not ask, generally they will at best close the pull request without comment (worse case), or best case they leave a comment explaining what the procedure asking you to update your pull request. I will say it does seem odd the way the maintainer in your case handled it, but it may have just been the path of least resistance for them. I doubt it was intentionally meant to steal credit though.

I would suggest you ask the maintainer to add documentation explaining how they would like to receive pull requests and against what branch to avoid the confusion and lack of credit in the future. I wish more projects provided this documentation, as I think it would make people more inclined to participate in the project.

Improve this answer
1

I’m not a big-time OSS developer but I’ve never seen this practice.

It’s also completely unnecessary.

  • Some Git workflows incorporate patches from email, which means that a new commit will be made when the integrator/maintainer imports it. But the author is maintained because of the author/committer distinction.
  • With cherry-pick/rebase you have to explicitly go out of your way in order to change the author of the commit.
  • Projects on GitHub often use merges to incorporate pull requests. That means that the maintainer can simply add some commits on top of your branch before merging if they’re not completely happy with the proposal.
  • But if the author wants to edit the commit then they can add themseles in a “Co-authored-by” trailer in the commit message. This is a fairly widespread (used) trailer and GitHub supports it now (2023).
  • And if they really want to rewrite the change then they can still at the very least mention the author of the original pull request in the commit message.

Simplest explanation

The mantainer didn’t know about git-cherry-pick(1)/git-rebase(1) and copy-pasted the changes and made their own commit.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.