Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

migrated from stackoverflow.com Aug 8 '12 at 20:31

This question came from our site for professional and enthusiast programmers.

5  
+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 '12 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 '12 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 '12 at 18:20
5  
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 '12 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 '12 at 13:19
show 1 more comment

4 Answers

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

share|improve this answer
add comment

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.

share|improve this answer
1  
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 '12 at 12:33
add comment

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.

share|improve this answer
add comment
up vote 1 down vote accepted

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.

share|improve this answer
2  
Then they should have used git cherry-pick. –  svick Jan 26 '13 at 17:33
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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