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?
6
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.
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.
1
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.
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.
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.