Learning more about Git…

I’ve been using Git for couple of years more or less frequently. Mostly I’ve been using git when developing Cppcheck. In past months I’ve also used git at work. Some time ago I’ve finally looked at really using git for my OSS development work with Cppcheck.

So far my git use with Cppcheck (and other projects) has been very simple. Just pulling latest changes to master branch, committing and pushing commits to same master branch. Cppcheck development does not use feature branches, just the master branch. And my contributions have been pretty small and straightforward touching code that others haven’t been touching (much). As I’ve mostly worked with Windows support and GUI.

Then I decided that I finally want to improve cppcheck Windows integration. It is barely working but a bit messy and there is a lot to improve. Similarly I wanted to look at really improving GUI.

For that I didn’t want to work in master branch. I didn’t even want to work on Dan’s tree because I would be experimenting a lot. Yet I want to share my code for others to comment and discuss. I was curious if git can do all this for me?

Luckily there is GitHub! I can make my own clone of repository with single button click. Then I can work on my own clone as if I was working on Dan’s tree. I can even add branches from Dan’s tree as branches to my own repository. So I can easily follow also the upstream development and merge upstream code to my changes. This opens lots of new interesting possibilities for sharing work and code.

Experimenting with some of the possibilities took couple of days and quite a many deletions of repositories and cloning them again. But it was definitely worth of it! I’m actually starting like the possibilities and flexibility of git! And I feel I’m only scratching the surface here…

I think git is power user tool. It requires quite a bit learning. It is quite frightening for people like me coming from simpler (and more restricted) tools. You can start using git pretty fast for simple things. And I guess most users are happy with these simple usage patterns. But if you really want to take advantage of all the possibilities of git you need to reserve time for learning and experimenting.

And if the simple use is all that is needed then the git might be the wrong tool. For example Mercurial and Bazaar are simpler and easier to use in many cases. And easier to learn.

3500 commits (and six years)

Yesterday I noticed that my commit count in ohloh.net has reached 3500 commits. It is the amount of commits I’ve done to public Open Source repositories that ohloh.net tracks. It took about six years.

Now, that number is something one can proud of and it is public record. It is not the whole truth however. I don’t have easy way to prove it but I think my real commit count is over 4000. The reason? Ohloh.net tracks only commits to SVN trunk. So all branch commits are missing. We have sevenrelease branches in WinMerge and every release branch easily gets fifty or more commits by me. So 500 commits to branches sounds realistic. But as the 3500 is easy to prove and clearly visible it is better number to use.

Another unfair point with this number is that all commits are not for my work. I’ve just committed lots of work done by others. Translation updates are one example where I just commit work of others. I always give the credit in commit log (and in contributors listings) but again there is no easy way to tell how many my own patches I’ve committed.  However, I do some work for every commit. I build, test, review etc. So I think it is fair to say all these commits are my work too.

How about this another number, six years? When I contributed first patches for WinMerge I merely did it so that I could give back something. I never intended to become a regular developer. Indeed I did not even care if my patches were accepted or not. Of course it was nice they got accepted quickly. And the last thing I needed back then was taking responsibility from a software like WinMerge. I was using some Open Source software but knew very little about development models, tools and so on. It was totally new world and development model for me.

All that learning has been the best side of all this Open Source work. You must learn something new almost every day. It has been a big benefit in my day work too. Many times I’ve noticed at work that I already know the tools and libraries I need to use.

Everything I do is public. Every good idea and clever piece of code (when I some day write one…). But errors too! It is not nice when people see all errors and mistakes. There is no way to hide anything once it gets added to public repository. It was a bit shocking at first. Sometimes it is quite embarassing to find out that bug is caused by my own commit couple of years earlier. But I’ve never really seen finger pointing in WinMerge. Its not important who did it (error). It is important we fix it. This is one thing I really like in current development team.

It has been a fun six years with WinMerge. And although I need small breaks now and then I’ve no plans to stop contributing. There is so much work to do. WinMerge is good, but it could be so much better… For Frhed there are lot more serious alternatives, but I think it has its own good sides. Maybe it won’t be the best free hexaeditor but it will be one good hexeditor with some unique features.