The Martian Chronicles

Why I'm using git in my Pharo projects

A couple of days ago, Torsten Bergmann asked me why I'm moving my Pharo projects to Bitbucket.

He expressed doubts because that makes more difficult the task of possible contributors, because it would imply the use if an external tool (to commit and push/pull changes), to get an account and also to get used to the differences between and monticello (none of those necessary with actual configuration).

While not completely appropriate, I took the opportunity to explain all the reasons of my move, then I answered in an extensive mail. After, I thought it might be a valuable blog post (yet a debatable one), so I edited it a bit and shared it here.

So, let's see what do you think :)

Ark

There are several reasons to adopt a versioning system different than the good-old-monticello (and particularly, its persistent formats). Reasons that goes beyond the specificity of just a versioning system. Reasons both practical and projective, for the long way.

Using git I can take advantage of the growing platform around it.

Yes, that's one big and good reason. Bitbucket allows me to manage better my projects. Using it, I can have centralised sources, issue tracker, wiki, etc.

Also I can have a better management of the contributions through pull requests.

Yes, adopting bitbucket there is still valid the question "why you choose Bitbucket and not the more popular GitHub?”. Both have a good set of features, but github is slightly better according to almost all reviews.

I have a personal reason (but I think is a very good one, that many can share with me): Bitbucket allows me to have private, free, unlimited repositories and I already have some personal projects there. For me is easier to have everything in the same place, but using Bitbucket, Github or even Gitorious will not make the difference.

But there are some concerns about the use a new versioning system, in particular two:

1) using git forces users to use an external tool (git and probably one of their GUIs), and thats far from the original spirit of Pharo.

This is a valid concern, and it has to be taken care.

  • Yes, we need to create the tools to manage git repositorios directly from image (using libgit2), and they are on the way... I hope for Pharo 4 we will have a good tool running in image.
  • In the mean time, you can still use it, and you just have a single extra step. There is a tool made by Thierry Goubier (gitfiletree), that can help to avoid the complications, but it is using external commands so you need to have a git client installed.

2) Users need to learn a new repository manager, get accounts, etc.

I disagree with this argument, because I think that is quite the oposite: nowadays almost every programer has used git and it will not be really far from their current experience (the one they have outside Pharo). Also, the transition from Monticello to git is really smooth: You just declare a new repository of type "filetree" in monticello and you can start using it.

Projecting the future

But beyond the practical reasons, I have some others that are not so immediate but I'm sure are far more important. There are probably more, but so far I summarised some in the following points.

Pharo is growing.

Which is a good thing, but has some problems associated with his growing. Is a fact is that we cannot manage Pharo anymore as a small project with a small number of contributors. Is truth that it is far away from other platforms, but anyway we are facing problems related to the amount of people that uses pharo, contributes to it and exchange code. Smalltalkhub is not enough, and it requires from newcomers to learn yet-another-source-manager (If your concern is for the non-users of git to learn it, my concerns are for the non-users of Pharo to learn monticello, and those are the ones I want to seduce).

I think Monticello is doomed.

Why? Well, when the first version of Monticello came the competitors were CVS (and probably SVN, I do not remember), there were some commercial options also but not really an option. So, Monticello was a great tool for the moment.

But time passed and nothing changed there, and then emerged things like darcs, then git and mercurial. And along them they came the websites like GitHub, who complemented tremendously the tools and IMO changed radically the way you do open source today (and in a positive way).

There are also other small problems related to monticello, like the fact that today a project is not just the pharo code in 99% of the cases: there are external files of many types.

If you keep those sources separately you end having a lot of problems. Take the case of PharoVM as an example: VMMaker (a monticello package) and external sources (in SVN first, then Git) were maintained separately and as a result of that it was extremely difficult to match the sources in case we wanted to make a rollback (something really common, when you deal with the VM ;) ). Of course we could try to catch up...

We do not have the strength to fight in all the fronts.

We cannot make a Monticello and Smalltalkhub as cool as git and GitHub, and at the same time still do Pharo. So we will always be behind the state of the art if we try to do it. We shouldn’t even try, instead we should focus on making Pharo and all the things that will make Pharo ready for the 21 century.

Pharo should not be alien just for the sake of been.

We have a great development platform, with a huge potential. But we also have a platform that is difficult for newcomers.

We should not put more barriers than necessary: we will not change syntax, because is vital for the Pharo experience, and we will not go to program in text editors, all of that would be shooting us in the leg.

But if we can reduce the learning curve, by using something that most programmers already know, something that give us the same benefits that what we had (and much more, in the case of git).

Well, that's better!

Conclusion

I think my reasons are good. There are others, like the visibility for you and your projects (and Pharo in consequence) gain by using a popular platform. But main reasons I have to migrate to bitbucket have been exposed.

And I would love you to join me too!

Posted by Esteban at 23 January 2014, 1:05 pm with tags pharo link

Comments

I absolutely agree with you. The only valid reason not wanting to use git repositories for Smalltalk is the current limited tool support. But that is changing and will grow as more people switch.

I feel a lot of opposition in the community driven by the same force that is keeping non-Smalltalkers away from Smalltalk: fear of stepping outside the comfort zone. We should really know better and the reasons are outlined in your post.

Thanks for the post.

Posted by Johan Brichau at 23 January 2014, 5:57 pm link

While I like that you publish your thoughts as a blog post in public it would be really valuable when you would reflect correctly what was discussed from the other (in this case my) side.

From reading your blog article above one will get the impression that I (personally) was the one who raised all these concerns: - about a different UI - being forced to get used to another tool - a different spirit (whatever that means) - ...

WHICH I DID NOT!

Hey - I'm totally fine with Git, SVN, ... Non-Pharo tools, bitbucket, your personal preferences for managing your accounts and projects, ... In fact I like and use many of these tools.

Note and remember that the topic under discussion was "Contributor for Voyage" and that the only statement from my side was: its not as simple as before to contribute.

While in the past one could contribute easily only with the development/target platform installed one now needs to follow the same route you went.

As you know the default image (which is 3.0 these days) does not support git or gitfiletree out of the box without a little tweaking. And this could be a barrier for others to contribute to Voyage.

And I doubt that someone outside to the ST community who is familar with Git will now contribute to Voyage since it is accessible on Bitbucket. To contribute he would still have to master the language and development style.

So this was a discussion about "easy contribution for Voyage" and a completely independent discussion from the possibilities of todays versioning tools. Git itself is cool (funny enough this is something I said about Envy, Subversion, Monticello, Mercurial in the past too ;)!

So to make it more complete here my original mail:

Hi Esteban,

is there a reason for mving to bitbucket?

It may help you better manage the code but from a contributors point of view it gets more complicated (one needs additional git, bitbucket account, ...)

Thanks Torsten

I stay with my points: it allows for easier management on authors side but it is not as simple as before to contribute when there is a minute.

Posted by Torsten Bergmann at 23 January 2014, 6:25 pm link

Hi Torsten,

I'm really sorry if my post gives the bad impression that you were opposing or fighting against any movement.

I just took our mail exchange as an opportunity to explain why I believe community should move to use an external source control tool.

I also wanted to say that many of the doubts that are around are valid (yours or from others), especially because our in-image tools are still not mature enough.

But I also wanted to express my confidence that they will be, for Pharo 4, if we put an small effort there.

Again, I'm sorry if the post give the wrong impression about your opinion... I edited it a bit to match better the spirit of our exchange.

cheers, Esteban

Posted by Esteban at 23 January 2014, 8:02 pm link

Good points.

Lowering the entrance barrier doesn't require changing the language.

But it does require something we aren't used to do.

Great APIs and great UIs

Actually APIs are non graphical UIs for coders

Posted by seb@sebastianconcept.com at 24 January 2014, 4:35 pm link

You are absolutely right. But for now I think that workflow is completely fucked up, because in order to work "comfortably" with git I have to do quite a lot of shamanism with drums :) Moreover I don't know what should be a correct support. Maybe launcher should know about all your repositories (projects) and then when you want to develop a project it will download an image an inject the project & repo to there…

Posted by Uko at 1 March 2014, 10:25 am link