Let's Push Things Forward

Maximizing social utility for fun and (modest) profit

Previous Entry Share Next Entry

A clear DVCS winner for Gnome


I think you may be right that we may not switch to a single DVCS any time soon, but I don't think it's for lack of a clear winner.

The majority of Gnome developers pushing for DVCS seem to favor git (with bazaar at a distant second). Major open source projects (many related to Gnome) have already adopted git (most freedesktop.org projects, X.org, Linux, Ruby on Rails, OLPC), so there's plenty of experience both using git for large projects and migrating from another VCS.

At any rate, I think there are few people who disagree that DVCS of some kind could improve Gnome development (most interestingly, I think, is the possibility for changes that don't fit nicely into a few commits or a single release cycle).

I'm not claiming that I fully understand all sides of the argument (git is the only DVCS I've used), but the only arguments against git that seem valid are cross-platform issues (which seem to be less significant than they used to be) and migration issues (which we would have moving to any new VCS, and as Federico suggested, shouldn't necessarily be that bad).

I wish it were as simple as just providing mirrors or translation services to let developers use any VCS they like, but any translation between VCSes is going to be imperfect. So using x-to-Subversion really isn't ideal - especially when you're going from a DVCS to Subversion, flattening branches and commits and losing original author attribution in the process.

I know I'm not alone in saying that a migration to git would be a major step forward for Gnome and one that few contributors would regret.

Update 1: link to cgit.fd.o, as suggested by Daniel

  • 1

You're forgetting GNOME experience

With my blog I meant that you have to investigate GNOME infrastructure and what has to be done to make a switch. The GNOME infra is not the same as fdo, it has a lot of specific GNOME stuff. Those are not unsolvable, but they should not be taken lightly. Further, I don't see any GNOME sysadmin doing a conversion to Git (I'd love to be proved wrong).

A lot of the projects you mentioned are very Linux specific. GNOME is not. Further, there is a strong push for Git, but I don't get why. I understand why Bzr is not good now, but I do know I'd consider it good enough soon. Just an ack or consideration of the problems with a roadmap to fix.

The current treatment of core infrastructure to me is very strange. Especially considering the Beast problem during CVS->SVN, the restart of the whole conversion process. The various problems found during Beast testing, etc.


Re: You're forgetting GNOME experience

Right - I don't mean to trivialize the migration process. If I thought I could trust myself to do it, I would volunteer :) - I just mean that any issues are not insurmountable.

There seem to be a few full git conversions of Gnome modules (see the last section) - even GTK+ is in git upstream (I wish I'd realized that in time for the original post).

As other commenters have pointed out, much-improved Windows support has already been migrated to the upstream git.

And we certainly could use more sysadmins on your level. I wish I had a good solution for that :-/

Re: You're forgetting GNOME experience

There is in fact a full mirror of all git repositories available at http://git-mirror.gnome.org/

Re: You're forgetting GNOME experience

I'm curious how fd.o is somehow less portable than GNOME? Given that we have X.Org, Cairo, HAL, Loudmouth, D-Bus, Mesa, and others on git.fd.o, and GNOME depends on several of these (X, Cairo, D-Bus, and to some degree Mesa), you're screwed if git does somehow sabotage cross-platform work.

Please link to cgit.fd.o rather than gitweb.fd.o. It's a hell of a lot faster and often less crap. :)

Some tests I did this week show that Git is still faster on Windows than Bazaar. Not as much as on Linux, but still about 3x as fast. So speed should not be a consideration when running Git on Windows.

There have also been a lot of improvements in Git with handling case-insensitivity recently. The msysgit port also got merged into Git recently, so the next major release will fully support Windows, also without the cygwin environment.

Git and cross-platform issues

I strongly disagree that Git's cross-platform issues are any less significant now than before, relying on msys is a big no-no for portable software. (Anything relying on bash, coreutils, etc. is bound to be tied to UNIX, and run but run damn slow and have tons of integration and maintenance issues under non-UNIX systems like Windows.)
So saying that Git works on Windows is almost like saying that Microsoft Office works well under Linux, and point to instructions on how to install and set up VMware Workstation... Yes, it works, but no, most developers are not gonna wanna use it.
It's basically the same issues that you'll face trying to turn any Windows developer on to your favorite open source project, no matter how cool the technology is it's very likely that most will be turned off the second you take them through installing and setting up mingw and using autotools. Yes my dear friend, running 'configure' might take 20 minutes but it's okay, you should just switch to Linux if you get tired of waiting because of fork() implementations not being able to do copy-on-write and spawning thousands of sub-processes a second. And hey, it might fail because the OS sees it as a local DoS attack, but it's fine, just keep running configure my dear friend, config.cache is your friend.
Sorry, but Git's UI needs replacing, shell-scripts simply aren't portable and that makes Git orthogonal to OSes like Windows.

MinGW support

Just comment that the MinGW port is merged (http://git.kernel.org/?p=git/git.git;a=commit;h=18c1f31bb01ab1271527659e36a1d83471b51a8a)in the 'next' branch of git.git.

It means that the next version will have it (if all goes well).

I've been using hg for about six months on a private project and I have absolutely no complaints about it, except that I'd like to see a rebase-like feature. I don't remember actually taking some time learning it, it feels very natural and the manual is great. And I wish everyone would use hg. However... That's not the case - despite Mozilla etc, git got a lot of momentum with Rails and a huge chunk of web development crowd switching to it, together with web sites such as github. And yes, most GNOME developers are or have been using git at some point already. So I'd just pick git immediately and get over the endless discussions. We might actually help further minimize the DVCS fragmentation used within large projects as well.

Just wait for a finished libgit and a nice (maybe hg like) porcelain on top of it. -> Done.

All regrets become invalid immediately.

There is one more very valid argument against: usability and the need to know a lot about the inner workings. Fine for professional genius developers, but we do want to have artists, sound guys, managers, writers and others on board too, right?

Of course that's a valid concern. But I think the main operations for non-code are:

git clone
git commit
git pull
git push

In other words, there's just a couple new concepts and one new operation in that (the distinction between commit and push in DVCS). GUIs, like Giggle make those operations point-and-click (and Giggle even visualizes the source tree history).

So, it's certainly possible to do fancy things with git, but they certainly aren't requirements.

Are all git proponents just going to whitewash over git's usability problems?

I don't doubt for a second that git will eventually be choosen for gnome, I hope that at least a balanced study will be made of git's usability problems, and that corrective action will be taken before any switch is made.

Just look at this boggling excerpt from the description section of the git-rm manpage: "Remove files from the working tree and from the index. The files have to be identical to the tip of the branch, and no updates to its contents must have been placed in the staging area (aka index). When --cached is given, the staged content has to match either the tip of the branch or the file on disk."

That's a lot of jargon there, I hope users don't need a CS degree to use git.


The git man pages could definitely use a bit of clean-up. I remember being confused by what the man page referred to as a "tree-ish", I believe. When someone in the git chat room explained it, it was actually straightforward.

But I think it's mostly the fact that the git man pages make it look harder than it really is. So it's still a problem, but I don't think it's a fundamental one.

non-technical contributors

I am a developer, I have plenty of experience with various revision systems and git is not exactly transparent even for me. It is clear it takes a real effort to dig down and grasp the concepts and how to work with git in a safe manner.

A major class of contributors to Gnome are the translators who, as a group, probably are as many as the developers. Most translators are not programmers; they translate in part precisely because that is the way they can contribute - documentation writers are another, smaller group.

SVN is already a pain point for translation, as evidenced both by the frequency it comes up in translation mailing lists and in repository-related problems caused by translation team members. Moving these people over to git would be ..challenging. Be prepared to have lots of nontechnical people do strange things to your repository, and see translation levels drop.

That, or suggest a way non-technical contributors can get around this stumbling block and check out and check in their work without being exposed to a VCS directly.

Re: non-technical contributors

Right - any VCS is a really bad interface for a translator. A decent web app would work a lot better - just have original strings on one side and text entry boxes next to them. I believe that's what Launchpad's Rosetta already does. I'm sure there are other non-code tasks that would also be better served by a simple web app instead of raw VCS (eg, updating icons).

Again, git is not the complicating factor here.

For translators, transifex does provide a unified web interface and is being used by Fedora heavily already. Moreover, the workflow favours upstream better and is completely Free and open source software. Take a look at http://transifex.org for more details.


If folks were to put a fraction of the effort / interest into Linux debugger / development tools as they do into various and sundry version control systems, we would have a truly awesome platform.

That is sort of what I fear about GIT. Debugging and developing for Linux is non-trivial and has a huge barrier for entry - especially at the embedded Linux side of the spectrum. GIT simply is consistent with the current state of debuggers / development tools - ultimately command line centric w/ many cryptic commands.

I don't see that changing sadly.

If it were a question of moving from one centralized VCS to another centralized VCS, I could see your point. But DVCSes really bring a lot of significant improvements to the table. The ease with which a DVCS lets you get a fully-functional check-out without having to ask for permission as well as the ability to commit many times before pushing to the mainline are huge for me. And git itself (probably other DVCSes as well) makes it really easy to combine commits into nice, clean patches (which is another huge plus for developers).

As far as difficulty debugging and developing in Linux -- what are you referring to?

Difficulty for ISVs to work on a platform with limited ABI stability? That's true for the kernel but Gnome has a great record there?

A lot of that is up to personal taste - I'm sure some non-Unix-centric developers prefer big, feature-heavy IDEs, etc. (not that we don't have a wide selection of them), but I haven't found a lack of decent development tools in Linux.

GIT is great, but not on Windows

I'm not a GNOME developer but I try to contribute somehow.
GIT is a great DVCS for me, I use it in my projects. I've also used bzr and hg but GIT is my most favorite VCS for several reasons.
The only problem is that I encounter troubles when working on Windows. If I've written a file say in UTF-8 under Unix, once I clone the repository under Windows I get the index dirty as soon as some terrible mechanism will convert a couple files to Windows CRLF. It happened sometimes ago so I don't know if it's still happening with later versions. But yes, I agree GIT isn't as portable as others.

  • 1

Log in