Dealing with rejection in git, resetting your master to theirs and starting over

You haven’t really started using git until you’ve gotten your first patch rejected. Due to the nature of git, merging is easier, but rejection is harder. Well if I was using branches it wouldn’t be that big of a deal, but thats besides the point.

You see I developed a love/hate relationship with a wonderful NoSQL database called MongoDB, that led me to contribute patches to it. I loved it because its awesome for a few specific tasks I need to do, but found its windows support a little lacking. It ran and performed great in windows, and even ran as a proper NT Service. However, it needed a little spit and polish. It was also a great excuse to do some hardcore windows system programming, and logging calls. Ask any sysadmin that ever had to support a program I wrote, I love verbose debug logs.

So every once in a while one of my pull requests got rejected. The first few times it took me a while to deal with it. I don’t mean it took me a while emotionally to deal with the fact that my code is anything but perfect. I mean that it took me a while to reset my git repo with the main 10gen repo. Sure I could have deleted it and started over, but I wanted to learn how to use git properly.

So in the end I asked on the Long Island Linux User Group’s mailing list and got a helpful reply from Mark Drago. I actually linked to my reply to his reply, since I make a correction. So without further ado, here what I did.

Ok a little more ado. My repo is refereed to as origin in the config and 10gen’s is referred to as 10gen. I wanted to save my master branch’s current state to a newly named branch delete my master and pull from 10gen’s master. In the end my problem was I never did a git fetch.  The final sequence of commands I did type was:</ado>

  • git checkout master
  • git checkout -b oldmaster
  • git branch -d master
  • git fetch 10gen  #Needed to get the list of branches in master.
  • git checkout remotes/10gen/master
  • git checkout -b master
  • git push -f origin master

And that was it. I was free to continue to write code.

Github, because software kittens should be cloned, not adopted

This is a tale of two open source software projects. However, unlike two certain European cities, there fates are not particularly intertwined, and there is little greatness about their history.

The projects are mqmanager, and console. Mqmanager is a tool for managing MSMQs written in .NET. Console is a multi-tabbed wrapper around cmd.exe.

Both projects are hosted on sourceforge. Neither project is terribly popular, although console is more so than mqmanager. The difference is in the SCM or source control management.

See mqmanager uses SVN, after a CVS migration, while Console uses git. More specifically Console hosts git on github.

“Whats so special about github?” you may ask. Well, mainly the forking presentment, or more specifically the one click forking. See, svn is centralized source control management, there is one repo that everyone reads from and writes to. In git, everyone has a full copy of the repo, and people can push and pull from each other based on network availability and security settings. More importantly, every open source git repo (they have a paid for option for closed source hosting) on github has a “fork button.” Want to fork project? Make an account, login, browse to the project, click the fork button. You have a full copy of the repo, along with the ability to add issue tracking, downloads, etc.

Now your asking, “Doesn’t this make forking too easy?” Well forking in and of itself isn’t that bad. Current trends in SCM policies for commercial companies as well as open source projects. And making it easier to fork doesn’t make it easier to make anyone care about anyone elses forks. If I forked emacs or firefox, few people would use my fork, regardless of how long it took me to setup SCM. My fork would do little to distract any resources besides my own.

I established forking does little harm, but whats the benifit? The benefit, at least the one I care about is for the less popular projects. Console is much more popular than mqmanager, but neither are hugely popular. Neither have funding or a development team of more than one person.

When I found mqmanager, it was abandoned like a stray kitten. I contacted the original developers, and was given control of the project. I improved it, used it, and forgot about it. Someday someone else might make changes to the code that they want to contribute back to the community. They will have to find me, I will have to give them access to the source forge project, and they will be stock caring for the project.

With console its a different model. The sourceforge page has  a sorce archive and a binary archive. I wanted an installer, and I was willing to write one myself. I made an account on github, forked the project (there is a fork button on each repo that will fork any project), made some changes, committed to my branch, and sent a pull request to the original author. Github makes it quite clear that I am a fork of bozho, and bozho can accept my changes at any time. A year from now someone can fork my version and send bozho and myself push requests.

The benefit of github is you don’t have to ask permission. Your cloning my kitten, not adopting him. Thats important for smaller niche open source projects. If I write a niche open source product, I probably won’t be using it regularly two years from now, but someone else might need it. The decentralized github model works better than the forge model for this.

I have adopted a few kittens over the years, and have a few kittens in need of adoption. I plan on migrating all my OSS project over to github. I will keep up the sourceforge pages, but  strip most of the sourceforge functionality to encourage use of the github pages. Perhaps people will fork these projects. Maybe at the time I will be to busy to evaluate their pull requests, but in the end my software . . . my craft . . . my art will live on and hopefully be mare more useful by others.