Re: On Version Control Systems

I would like to add some points regarding Lennart's last post on Version Control Systems (sorry for such a long post, but I wanted to make my point here ;-)

First, I completely agree on Lennart's first point that DVCS is not the solution to all of our pains and it won't make people suddenly write better code.

However, I strongly disagree that our decision should be done following a popularity contest, the decision should be taking thinking in the long term impacts of it, not just about the current situation. Okay, the Linux kernel choose git, X.org and consequently fd.o too, but we shouldn't give for granted that if it's a good decision for them it's a good decision for us.

We target to a quite different developer base than kernel.org an freedesktop.org, our project works differently, our culture is different. We sometimes forget that VCS is one of the key entry points for new contributors, the harder it is to learn the VCS, the harder it is to contribute to our project (actually, I would say that DVCS are harder to learn than SVN).

Git is probably the responsible of the current popularity of DVCS, specially after Linus talk at Google, but despite having the best performance and probably being the most popular has its drawbacks as well, and we might consider the impact of those drawbacks on our particular community.

First drawback is usability, at this point git is extremely hard to understand because of its inconsistent and weird semantics and the lack of proper error reporting that denies users to be able to instinctively learn what needs to be done to solve the problem plus current documentation is extremely poor. Now imagine the frustration of new contributors while learning how to create a new project or contribute for their first time to GNOME. I don't think asking people who are already used to one DVCS to learn another one is a big deal compared to force new users, that might not even used a centralized VCS ever, to go through that pain.

Second one is the lack of a portable and reusable design, git is too tied to a UNIX environment, for it to work on Windows it requires msys, curl, perl and other UNIX specific bits this makes really hard to maintain a high quality port of the tool, and ties a Windows user to a bash terminal to effectively use the tool.

Of course we all love the flexibility that a shell based implementation allows by using pipes and that stuff, and that's fine for kernel developers or X.org developers because its source code is aimed to Linux/OpenSolaris/BSD developers in the 99% of the case.

However we have projects at gnome.org svn that are supported on Windows, such as Gtk+ or Evolution. Setting up a development environment on Windows for a GNOME project is hard enough at the moment, using a tool that won't work natively on this platform by design won't make the situation any better in my opinion and this will prevent new contributions from other platforms happening.

On the other side, this design prevents the effective reuse of git from other tools such as IDEs or web services without accessing the command line, which drives to security issues and less maintainable code.

Comments

[Jason D. Clinton]

I asked that this discussion happen on the mailing list instead of PGO but since we're on a chain now, I guess the cat's out of the bag.

I want to simply add that your information about Git is outdated. The curl and cpio requirements have been reimplemented in C in git's own source as of 1.5.6. As far as Windows-ness, it's basically on-par with all the others: they all have a heavy reliance on a command line syntax.

As for the usability, I picked up Git over the past few weeks and am even using git-svn to manage my module. I found the documentation excellent and the error messages when I do something stupid very helpful. (ie. "You are doing X which seems stupid. Perhaps you meant to do Y?")

git-svn could use some more usability work but that's irrelevant if Git is the upstream.

[Zeeshan Ali]

Jason said it better than I would have. One thing I felt while reading this blog entry is that it's a bit self-refuting: You talked about "long term" impacts and then mostly pointed out the current (as Jason pointed out they are already old) shortcomings of git that are very fixable.

What is important in this picture is that git is more of a filesystem/design and it's very good one so anyone can write a better (more portable and simpler) implementation of it if he is not happy with the current one and isn't very hopeful about it becoming as good as he/she wants it to be.

[blah]

Dude, you're spreading FUD on GIT. What you have said might have been true a year ago or two, but it is not anymore, if it ever was. GIT is certainly not "extremely" hard to get, and the documentation is not "extremely" poor. The only thing that might be "extreme" here is your FUD. ;-)

And what good would it be if new contributors would be tought some bizarre VCS which they then cannot use for all the other projects out there? In the end it is more work for new contributors to learn two VCS than just one that might have a bit steeper a learning curve!

Also, last time I checked there was a native GIT port to windows that doesn't rely on cygwin. And the current version of GIT doesn't require curl anymore. Also, python ain't that great a dep either. Also I am not sure why you claim that we should care more about Windows that fdo or X does. Windows guys will always have a harder time doing their stuff, that shouldn't hold us back. And Gtk+ is very much irrelavant on windows anyway. Certainly less relevant than X.

[J]

Jason: A couple of dependencies is irrelevant in the bigger picture; Git's UI is nothing but a bunch of shell scripts; which per se is not very Windows-friendly. And no, a self-contained installation with bash and all doesn't solve the problem at hand -- because having a UI put together with duct-tape, pieces of paper and glue doesn't really solve the integration issues for IDEs and similar. It's sad that Git's more of a hack than anything else, and what's even more saddening is that it's got hordes of fanboys that blindly assume it's the best thing around just because of who its author is.

[pclouds]

Git does require curl (library version, not executable).

If you want IDE integration, why not try jgit?

[Anand Kumria]

If you want a GUI, try git-cola, http://cola.tuxfamily.org/.

Or one of a great number of others.

[Tester]

Yes, git is not perfect, it "UI" is in many ways quirky and complicated (even though its improved). But, it seems works better than the other DVCSes I've tried (darcs and bzr). And more importantly, it has momemtum. I think the benefit of having a standard is greater than the benefits of the various features of the other DVCSes or the Windowsness... I don't know any of the other DVCSes has a windows gui..

[Nick]

Have you looked at the documentation at http://git.or.cz/#documentation ? Id say thats more than enough to cover most usage, plus there are numerous sources of documentation floating around, describing anything from the base command set to complex workflows.

Command based usage of git has different semantics than say mecurial or bazaar or svn etc, but i do not see how 'git is extremely hard to understand' anymore so than those previous tools.

Im not saying the others aren't great tools, but I think if you read the documentation provided and tried it out you probably wouldn't come to the same conclusions.

[xx]

if(!TortoiseGit) assert(!windows_friendly);

:)

[name]

GNOME does not run on Windows - why is Windows support relevant at all?

[John Carr]

@name: Please remember that this is about svn.gnome.org, not the GNOME release set. Gimp is in there and has a Windows release. Gtk+, pygtk, and others also have windows builds. Some apps are also targetting Windows in the long run (Tomboy, Conduit, Banshee). So, no, Windows support is relevant.

[anon]

As I already wrote on lennart's blog, you might want to try vng, which replaces git's hard to unterstand interface with a more logical one, much like Darcs'.

see
http://code.google.com/p/vng/wiki/Introduction
http://labs.trolltech.com/blogs/author/tzander/

[Jakub Narebski]

Had this discussion happened [also] on git mailing list (you don't need to be subscribed to post, and there are various archives/interfaces to read, including NNTP/news/Usenet interface on GMane), git could have been (further) improved. This happened with (if I remember correctly) Carl Worth questions, requests and comments, which spurned UI improvements after 1.3.x (among others making "separate remotes" layout/mapping of branches default). This happened with creating "Git User's Manual".

About dependencies. Shell and Perl is wonderfull for fast prototyping (provided that SCM gives low level tools for scripting); on the other hand they are not very portable and introduce additional dependencies like cpio or curl binary... but there is trend to convert mature (both in UI as in features) parts of git in C, so called "builtinification" project. For example git has lost dependency on `curl` binary with rewrite of git-fetch in C (you still need libcurl if you want to use HTTP transport; if you don't need it, you don't need libcurl either), and dependency on `cpio` with rewrite of git-clone in C and changing git-merge. There is GSoC 2008 git project to rewrite git-merge in C.

You don't need to use command line: you can use one of many GUIs, including Tcl/Tk gitk and git-gui (it is provided by msysGit, native Windows port of Git), Qt QGit, GTK+ Giggle, etc. There are GSoC 2008 projects to add DVCS support for KDevelop starting with git, and git plugin for Anjuta IDE of GNOME, see http://git.or.cz/gitwiki/SoC2008Projects

[FK]

Let's update the information (2009-01-25).

Good/decent Git user's documentation:
http://book.git-scm.com/

Git for Windows:
http://code.google.com/p/msysgit/

TortoiseGIT project has started:
http://code.google.com/p/tortoisegit/

About Git being a bunch of shell scripts. The current situation is this:

$ ls -1 git-*.{sh,perl}

git-add--interactive.perl
git-am.sh
git-archimport.perl
git-bisect.sh
git-cvsexportcommit.perl
git-cvsimport.perl
git-cvsserver.perl
git-filter-branch.sh
git-instaweb.sh
git-lost-found.sh
git-merge-octopus.sh
git-merge-one-file.sh
git-merge-resolve.sh
git-mergetool.sh
git-parse-remote.sh
git-pull.sh
git-quiltimport.sh
git-rebase--interactive.sh
git-rebase.sh
git-relink.perl
git-repack.sh
git-request-pull.sh
git-send-email.perl
git-sh-setup.sh
git-stash.sh
git-submodule.sh
git-svn.perl
git-web--browse.sh

Take a close look. Most of them are either low-level stuff which you'd only use in low-level hacking scripts or one-shot conversion tools from other VCSes. Of the normal tools only a couple of commands are scripts. "git pull" is a tiny wrapper around "git fetch && git merge". Both of these are C code.