September 2011

Git… enough!

Jordi

When in the course of human events it becomes necessary for a software user to disparage a thoroughly hostile DVCS, there is no recourse but to blog about it. Thus, software diplomacy has failed, and we must face the fact that I irredeemably hate git. To prove this, let these facts be submitted to a candid world.

We, therefore, appealing to the wellbeing of all software users, do in the name and by the authority of all distributed version control system decency, solemnly publish and declare that git really fucking sucks, that the previous obscene intensifier was fully necessary, and that we should do all that is within our power to reduce and minimise the proliferation of git usage.

Why I must write this

Before I proceed with my study of git hate, I must first present an apologia for why I am writing this.

You may tell me, “fine, you hate git, don’t use it. It’s just your personal preference.” Normally, for any other software I use out of personal preference, I would agree. I am a student of the Church of Emacs, but this does not mean I think everyone should use Emacs. As long as you produce text, I don’t care how you do it. You can use your text editor of choice, I can use mine, and we will both be happy doing so.

Unfortunately, the same does not hold for git. Although git can be used in isolation without ever collaborating with anyone else (after all, it is a distributed version control system, so this makes it easy to use without other people or a remote server), this is not its primary use case. If everyone around me is using git, then I am too coerced to learn git if I want to collaborate with their software development. You may argue that I can use another DVCS because everything can convert back and forth to git, but interoperability can only go so far. Eventually someone uses a feature of git that another DVCS doesn’t implement, and I will have to use git anyway.

Moreover, it is clear that git is creating a community of people who are faffing around learning gitology and feeling good about themselves for understanding abstruse concepts which are completely orthogonal to actually getting work done. This is evidenced by all the blog posts written by people being frustrated with git. As the renowned 20th century mathematician G. H. Hardy once wrote, “it is a melancholy experience for a professional mathematician to find himself writing about mathematics. The function of a mathematician, is to do something, to prove new theorems, to add to mathematics, and not to talk about what he or other mathematicians have done.” In a similar vein, it’s a melancholy experience that we spend so much time blogging about how to use git, reading blogs about how to use git, and joke about using git, instead of getting work done. Without git.

Because everyone else is wasting their time praising and discussing git, the aptly-named stupid content tracker, I must now waste my own time to point out how blockheaded it is that we spend so much time learning the tool that should be tangential to our work and ultimately unrelated to our actual work.

What will not be hated on

I want to make it perfectly clear that I will direct my hatred at git and at git only. In particular, none of the following will receive any direct dosage of hatred:

  • github
  • magit
  • git Tower
  • gitg
  • TortoiseGit
  • Your Favourite non-commandline Interface to Git
  • Whatever other tool for tracking content that happens to use git as a database or whatever

I want to make this clear, because these tools above are the reason many people claim to love git. But just because good tools have been built on a horrible core doesn’t mean the core is good. As an example I will frequently come back to, C++ is a horrible language, but many good tools and frameworks have been built on top of it.

To all the hardcore git lovers out there, git is neither necessary nor sufficient for building all of the tools you probably love that have been built on top of git. The facilities git provides to build these tools on top of it could have been provided by any other DVCS. We can and should do better than git without sacrificing any of the things you love about git, other than whatever tool has been built on top of it.

Furthermore, I also want to make this very clear: the ultimate enemy is centralised version control, not git. CVCSes are what’s really slowing our collaboration down. git is only the major enemy within the DVCS camp, but if you’re forced to choose git over any CVCS, and git is really the only choice for a DVCS for you (this is rarely true, but I’m speaking hypothetically here), then, yes, choose git. It is by far the lesser of two evils in this hypothetical Catch-22.

What will be offered instead

I will frequently cite Mercurial, abbreviated hg, as an alternative to git. I contend that Mercurial is a safer, saner, better designed, and no less powerful alternative to git. While it may be true that Bitbucket, the major non-free provider of Mercurial hosting often compared to Github, may not fulfill the requirements you have come to expect from Github, this is not due to any limitation of hg itself. As I said, I want to only argue that git as a building block is rotten, but this is not directly related to how people have managed to polish this particular turd.

I do not, however, want to be taken as simply a an admirer of hg who is used to an hg workflow and thus hates git simply because git is not hg. I will make a thorough effort to present sound arguments for the myriad reasons why git sucks that will stand on their own without comparing them to hg. When I am finished expounding my revulsion for git, I will offer alternatives that hg or perhaps another DVCS offers that demonstrate that git’s ugliness is not necessary.

Necessary. This is also a word I will come back to often. A central theme of my attack is that is that all the complications that git has created are not necessary. In order to demonstrate this, I need to offer examples of where git’s equivalent functionality exists without the parts of git that are not necessary. This is why I will frequently cite hg.

So, enough with the meta. Let’s get on to the hating itself.

Sage Days 30

Jordi

I wrote the narrative below a while ago, but I never got around to publishing it until now. I was present at Sage Days 30, a conference for Sage developers and users which took place in Acadia University in Wolfville, Nova Scotia.

Wolfville, Nova Scotia

I first need to make some remarks about the trip itself, which contrasts greatly with my last trip abroad into the US. I flew Air Canada this time, and I overall got a very good impression of them. Compared to the last airline I flew in (I think it was United) it was nice to actually feel treated like a human instead of cattle. Relatively comfy seats, food already included in the ticket, no idiocy like charging for checking in luggage, a very good selection of in-flight entertainment. I amused myself by watching as many French-language movies as possible.

I also want to remark upon the immigration experience. A few years ago, my compatriots started to behave very poorly as guests in Canada, in effect overwhelming Canada’s immigration services with spurious refugee status requests. As a result, Canada suddenly and without warning started to request visas from Mexicans, which caused quite a stir. I was very unhappy about having to go through the paperwork to obtain an entry visa, but all in all, it was handled pleasantly by the Canadian embassy in Mexico. The process took less time than their website warned it would take, and the requisite documents were relatively easy to acquire. And when I was at the border, I didn’t get finger and retina scanned, the immigration officer asked very basic questions, and I was through the checkpoint in less than a minute.

Airport security was also overall nicer than elsewhere. While they still have the idiotic rules of no liquids, my knitting gear went through security without a problem. I noticed Canada was also having the full-body X-ray scanners in place, but they weren’t being used. I did get stopped for a pat-down, but it was fairlly unobtrusive and the security guard didn’t put his hand between my legs. Not great, but not as bad as the US. All in all, I rate it 3 out of 5 stars.

This means we can still be friends, Canada. I’m sorry my fellow Mexicans were not being nice to you, but it’s good to see you’re still making an effort to be nice back anyways.

Then there was the experience of actually being in Canada. That was also overall pleasant in every way. En route from the airport in Halifax where I rendez-voused with other Sage Days 30 participants, we found a very chatty Hungarian cab driver who delighted us with stories of his native Hungary and present Canada. And once I actually arrived in Canada, Tattingstone Inn‘s managers are the amongst nicest people I have ever met. I have never felt more welcome or better taken care of. They accomodated for all of our requests in a luxurious old-fashioned farm home, delicious breakfasts, supremely comfortable lodgings, and all for a low, low price. I can’t sing the praises of our hosts enough.

And Canadian themselves, it’s truly astounding how polite they are, how willing to offer help, how welcoming they are, how generally aware of other cultures they can be. I already knew all of these things, but after being away from Canada for so long, I had started to forget them.

Sage Days 30

Now about the conference itself. It appears I walked into a rather tight-knit group of combinatorial algebraists who had very specific problems in mind they wanted to work on with Sage. The format of the conference was that the first few days were dedicated to getting neophytes acquainted with Sage in general and the tail end of the conference was dedicated to hands-on development on Sage itself. There were a number of undergraduates who had specific summer research requirements that were presumably being fulfilled by this conference.

I was impressed with a few characteristics of the community built around Sage and of Sage itself. Sage undubitably follows a free development model, but what’s interesting is how easily users can be turned into potential developers. It really is software for mathematicians, by mathematicians. In order to accomplish this, it does a few things differently than most other free projects I’ve observed. First of all, its main Mercurial source repository is only writable by a single maintainer. Everyone else sends patches for consideration. The driving motivation here seems to be that because these are mathematicians, not seasoned developers, the senior members of the community do not want to burden the mathematicians with the minutae of source control. In this same vein, I am convinced that Python was the perfect glue language for Sage. It is easy to learn, its syntax is very close to what mathematicians are used to thinking of, even if specialised programmers can find much fault for it.

The activation energy for collaboration is thus greatly reduced. I think this is Sage’s greatest strength. Every member of the community can easily make the transition from user to developer. Not to belittle Sage’s computational abilities, which are also quite commendable, but other projects like GNU Octave would do well to learn from Sage’s experience. I am working on how to make Octave collaboration easier too.

I enjoyed the socialisation in Sage Days 30 as much as the technical discussions and work. I was unfortunately not able to devote much time to the technical aspects, because at the time I was busy with technical work of my own for a job I have thankfully since abandoned in favour of a much more interesting position. But having dinner with mathematicians-slash-programmers provided me with a sort of mathematical human contact for which I was deeply starved. Playing ultimate frisbee and mafia (or werewolf, as they knew the game) with them was also a delicious experience. Playing mafia with mathematicians is a unique treat, because they treat the whole thing as an involved logic puzzle, analysing everything with great care. It makes for a very interesting game. I am happy I brought along my go board, which also generated some interest at the same dinner party where the mafia gaming took place. I was surprised to see that the game was new to a number of them, but they seemed to quickly pick up an interest in it.

Acadia University

I was glad to also spend some time seeing some of the academic aspects of Acadia, where I am considering returning to academia and doing postgraduate work. The university is small, and it doesn’t even have a PhD programme, but I would be able to work with some people from there if I enroll in neighbouring Dalhousie in Halifax. Recently, during the second trip I shall speak of shortly, I coincidentally met some Acadia alumni who had many good things to say about it, about the smallness of the community and the few distractions there are, which allows one better concentration on academics. It sounds lovely. I am sending an application there shortly, and I hope I can get in.

Code sprint

Jordi

Welcome to the sprint! Here is how it should proceed:

  1. From this list, pick an interesting function that you understand how it should work.
  2. Announce in #octave that you want to work on this function and also edit the wiki to say the same.
  3. Write a few simple tests for what you think the function should be able to do. Don’t attempt to test its efficiency, only if the function works. Use assert, error and test commands for writing your tests. Consult the doctstring for these functions if you need to.
  4. Once your tests are ready, put the special comment character %! at the front of all of your tests, and either prepare Mercurial patch (preferrable) or upload your changes to a pastebin (codepad is preferred). Or just push the patch if you have write privileges on Savannah.
  5. Mark the file as DONE in the wiki when the tests are pushed to the repo.
  6. GOTO 1