Friday, February 2, 2018

Pair programming with git

Git is great. It took the crown of version control systems in just a few years. Baked into the git model is that each commit has a committer and one author. Ofen this is the same person. What if there is more than one author for a commit? This is the case with pair programming or with mob programming or with any other way of collaboration where code is produced by more than one person. I talked about this at the git-merge conference last year. There are some workarounds but there is no native support in git yet.

It seems that the predominant convention to express multi-authorship in git commits is to add a Co-authored-by entry in the commit message as a so-called trailer. This adds more flexibility than trying to tweak the author and committer fields and is quite widely accepted, especially by the git community.

I'm happy that GitHub added support for the Co-authored-by convention now. It makes multi-authorship more visible. That's a good thing.

I did some work on adding native support for multiple authors in git. The direct approach of allowing more than one author field might be too intrusive due to the many possible side effects. But the Co-authored-by trailer is still a good solution. I have an unfinished patch to add some native support for that in git. It does need some more work, though.

Contributing to git is an interesting experience. The git mailing list is the central place. The contribution workflow is well-documented. It's good that Junio as maintainer has spelled out how he reviews patches and what that means for contributors. And it's definitely fun to work on a self-contained C project.

I'm looking forward to more multi-author support in git and GitHub. Pair-programming is a great model, and properly reflecting in the commit logs what happened when the code was written is the right thing to do.

Wednesday, January 31, 2018

Ruby on openSUSE

Ruby is a wonderful programming language. Every year in December as a kind of Christmas present there is a new release. It's great to be on a language which is kept up to date but it comes with the challenge to manage multiple Ruby versions. There are a couple of solutions around such as RVMrbenv, or chruby but they all have their drawbacks.

What would a Linux distribution do? At openSUSE, we package all the versions in the Build Service. We also package many gems but this is an effort which is sort of futile given the huge and growing number of gems and their versions. But you do reliably get the Ruby interpreter and gem tool as openSUSE package. To not create conflicts all the executables are suffixed with the Ruby version. That allows for parallel installation of multiple Ruby versions. It also works for all the executables installed through gems. The drawback is that you don't get the executable names you would expect because of the additional suffix.

So how does the ideal solution look like? We want the distribution maintained interpreter packages, the co-installability of multiple Ruby versions, the native executable names, and the full power of gem.

There is a nice solution to that. It looks like this:

Native executable names can be achieved by creating symbolic links in the bin directory of the user for the tools which come with the Ruby package: ruby, gem, erb, and rake.

Setting the GEMHOME environment variable to a directory in the user's home nicely isolates installation of gems. Parallel versions are handled by gem anyway. You don't need root to install gems and you can easily get rid of an installation if needed.

By setting `install: --no-format-executable` in your .gemrc you get executables with their native names in the GEMHOME directory. So you only have to set the PATH environment variable to let your shell pick them up so that you can call bundle, rspec, etc as it's meant to be.

All this needs a little bit of setup work. To make this easier we have created a tool for openSUSE to manage this for you. It's called orr.

With orr you can just do `orr install 2.4` and it installs the required packages, creates the links, and configures the environment variables so that you can use Ruby 2.4 right away. That works for any other version as well of course.

This setup brings you the best of both worlds, Ruby and openSUSE. Enjoy. And provide feedback.