Wine Maintainer Alexandre Julliard decided to try out the Git revision control system just a few months after creator Linux Torvalds released the first version – that was 10 years ago. Now, he says, “I can no longer imagine doing software development without it.”

Wine, the open source software used to run Windows applications on Linux, still mostly uses email to exchange and review patches. But Git is the project’s version control system (VCS.) Here, Julliard discusses why they use Git, their Git success stories, and pro tips for using the open source tool.

Linux.com: Why does Wine use Git?

Alexandre Julliard: It was mainly my decision, though at the time we were all tired of the limitations of CVS. I had been searching for a replacement for a long time, and I had written a script to extract the changesets from our CVS history and apply them to some other VCS; but every system I tried it against had problems of one kind or another.

Then when git came out, within maybe 2 months of the initial announcement, I gave it a try. Not only was it the only system that managed to convert our full history flawlessly, but it was faster than anything else I had tried by at least an order of magnitude. At that point it was clear to me that we had a winner.

What makes Git such a great tool?

It’s distributed, which is of course a huge improvement over CVS. It allows working off-line, creating meaningful commit series, revising things before publishing them, etc. As maintainer I love that I can

review changes as series of small commits instead of one big patch. I’m constantly asking developers to split their changes even more…

It’s extremely fast, even on a large project like Wine with 20 years of history. That’s important for me as maintainer since I have to merge a lot of changes; if I had to wait even a couple of seconds for a commit it would be painful.

I love that the data storage model is so simple, basically text files and SHA1 hashes pointing to them. That makes it very easy to grasp what’s going on, and to make sense of the more complicated commands.

How many developers do you have collaborating on Git?

At any given time we have maybe between 50 and 100 contributors. We still mostly use email (with the help of git-send-email) to exchange and review patches.

How much do you personally use it?

I use it pretty much constantly. Between my work as Wine maintainer, my day job at CodeWeavers (where we use git for everything), and a number of private repositories, I probably run git hundreds of times every day.

What’s Wine’s most active git repo right now and why?

We are using the centralized “integration manager” workflow, so the official repo on winehq.org is the most active. Most developers work on their private repo, though there are also a number of active forks on github.

What is your favorite pro tip for using git?

It’s not for everybody, but for Emacs users, I strongly recommend Magit.

I wrote the original git.el Emacs front-end, and used that for a few years, but it was never very good. I’m glad that people smarter than me have now tackled the problem, and Magit does a great job of making the full power of git accessible from Emacs.

Any git success stories you can share?

git-bisect is one of the best things that happened to Wine.

Since Windows applications have never been tested against another implementation, they depend on many undocumented side-effects of the Microsoft code; so any change we make can potentially break an application for seemingly unrelated reasons. This used to be a major problem for us, particularly since there are many applications that we don’t have access to.

Now with a few simple commands, users who notice a regression can bisect exactly which commit caused it, which enables us to fix it in many cases without having access to the app.

It’s so valuable to us that we built a web page around it (https://source.winehq.org/regressions) to shame people into fixing the regressions they have caused…

Anything else you’d like to say to mark the 10-year anniversary?

Since the very first days, I felt that git had a lot of potential, even though it was initially very clunky to use. I’m very happy that in 10 years it has more than fulfilled this potential, and become even bigger

and better than I expected. I can no longer imagine doing software development without it.

Read more Git Week profiles:

Git Success Stories and Tips from Puppet Labs’ Michael Stahnke

Git Success Stories and Tips from Tor Chief Architect Nick Mathewson

Git Success Stories and Tips from Drupal Core Committer Angie Byron

Git Success Stories and Tips from Qt Maintainer Thiago Macieira

Git Success Stories and Tips from KVM Maintainer Paolo Bonzini

10 Years of Git: An Interview with Git Creator Linus Torvalds