Felipe Contreras

I recently found out a few awesome tricks for git send-email that have made my life much easier, so I decided to share them here

First, git send-email is an essential tool in every git guru’s arsenal, as it’s the preferred way of submitting patches. All you need to do is generate your patches with git format-patch (preferably with a cover letter), and then use git send-email to send those patches inlined in a nicely formatted email thread with your MTA.

But do you know about the different threading formats, address-book queries, or the cc-cmd option? No? Well, let’s get started.

Read the rest of this entry »

codeswarm.rb is a rewrite of Michael Ogawa’s code_swarm in ruby using cairo.

For an example see:

The format of the events xml file is compatible with code_swarm’s one,
and the physics engine is basically the same.

The code is less than 500 lines of code, so it should be fairly hackable.

The code is there:
http://github.com/felipec/codeswarm.rb

And here is a picture (youtube is too blurry):

After developing a mtn to git conversion tool I understood much better how monotone works and why it does the seemingly crazy things it does. Once you understand the internals everything makes much more sense.

With the hope of shedding some light to the core developers of Pidgin regarding the DSCM tool (monotone) they use, I wrote an email explaining all the little details of monotone and how other tools do exactly the same thing in a simpler way. Here is the mail.

The results where mixed, some people discussed valid points, while others didn’t really try to understand and just attacked git, and myself. It seems some devs are quite fond of mtn and wouldn’t allow any attacks on it.

Anyway, at some point it was accepted that they didn’t do a good job at evaluating git, they discarded it because of the size of the repository (700M). Of course, they didn’t bother to read the manual, ask on IRC or in the mailing list. Don’t ask me why.

Apparently that discussion generated a post in John Bailey’s blog in which he explained why git is not a good option to him. That in turn generated a discussion in the git’s mailing list explaining that he was wrong, was doing an unfair comparison, obviously pushing his own agenda.

Then out of nowhere another discussion in the ohloh forums started. Basically an exchange between Gary Kramlich and me, in which I found out his blog post about a diagram explaining his typical workflow with monotone.

So I answered with this diagram, which clearly shows that exactly the same workflow is much simpler in git. I think in the end he realized that too.

So I’ve answered all their questions, and I’ve proved them wrong in their arguments, I’ve offered a hands-on session to clarify any misconceptions they might have. As a result I get John Bailey to call me a zealot that is not worth listening to.

Anyway, returning to the topic, here are some tips:

Don’t use an obscure DSCM

Even a popular SCM is better; your developers can use their decent DSCM (git-svn) to interact with it. If you choose an obscure DSCM you’ll have issues because of the lack of support, trac, web ui, desktop ui, free service provider (github.com), etc.

Also you make it more difficult for new contributors; they have to learn a new DSCM just to contribute.

Pidgin is the last major project that uses mtn, OpenEmbedded was using it but they decided to switch to git.

Don’t choose a DSCM that imposes itself

It doesn’t matter which DSCM you choose, not everyone is going to be happy with it, that’s why it’s a good idea to choose one that makes contributions as patches a part of the tool. Both bzr and git provide this functionality, people can send patches, for which they can use their favorite tool (git over bzr), and the maintainers can integrate the patches quite easily.

Not only that, but in order to allow reviewing the patches quite often need to be changed, that’s when rebasing comes. Both bzr and git allow rebasing, which is essential if you want to create nice patches, a la quilt style.

Moreover, bot bzr and git allow shallow clones so you don’t have to download the whole repo just to contribute.

Pidgin has a relatively big repository, so you have to download a tarball about 200MB, then do a couple of commands just to have the latest code. That’s because the initial fetch sucks in mtn.

Keep an open mind, but a closed mouth

DSCM flame wars can become pretty nasty pretty quickly, that’s why it’s a good idea to don’t participate in them. However, it’s good to be well informed about all the different DSCMs. There are other ways to be informed (private mails, or messages) discuss in the respective IRC channel of the tool you are interested in (#git, #bzr). That way you get the best facts pretty quickly instead of useless discussions.

Pidgin devs Some Pidgin devs on the other had, praise their good understanding of other DSCMs, and are quick to point out why others are not a good choice for them, all based on misconceptions. After lengthy flamewars and embarrassing blog posts their stand is still: git is not good for us. All the reasons they’ve provided have been flawed, so now they hang on to the reasons they are not disclosing.

Well that’s it, if you are a Pidgin developer, or monotone user, that wants to get to know git better just let me know, send me a message or an email.

Cheers.