A big part of maintaining open source projects is accepting others’ code; it is very important to handle it well so the code author wants to come back to us and help again. As much as the Ruby community is open source-oriented there are few things that can be improved. It happened a few times to me and other developers that the code was merged into projects without preserving authorship. This is a basic error made by maintainers, so I want to share some thoughts on how I try to avoid that problem when maintaining RVM. This problem mostly happens when the we want to change the commits, but is not limited to it and happens also without changes.
###The Easy way
When you do not care about number of commits you can merge the commit from Github or using
hub and then add new commit on top updating it to proper state mentioning the ticket number in commit:
git commit -m "Formatting ..., update #2195"
For example, see https://github.com/wayneeseguin/rvm/pull/2195
###Limit number of commits
The most basic method when you want to limit the number of commits is to apply changes from the committer and then commit it using the
--author flag. I used this for https://github.com/wayneeseguin/rvm/pull/2238 - getting the proper result with involving author would require too much work as for small commit, so I did the required changes to the code (just changing order of paragraphs) and committed it using:
git commit -m "..., closes #2238" --author "Name <firstname.lastname@example.org>"
It is important that the author matches exactly the original author name and email (from their commits) so it does not confuse others or tools used (like
git annotate). Also make sure to mention the pull request (
close #2238) so it is automatically closed and your commit is linked with it.
###Work with the author
The slowest way is to actually talk to the author and explain to him/her what changes are required to make his/her commit accepted. For example, this happened in https://github.com/wayneeseguin/rvm/pull/2187 where most of the discussions happened on IRC or Skype sometimes in comments. This way the person contributing gets best experience and getting back to coding on your project is much easier for him/her.
Matz Is Nice And So We Are Nice
Most important for maintaining your project is treating other developers with respect, they are human beings, being impolite just builds a wall and ensures they will not get back to you or your project.
Obviously there have to be other ways to handle this; please comment below if you use another flow.