Actually, he doesnt say the index is a bad thing. Just that the UI for it is kind of sucky. But soon Git will have a new name for this, woo! Hopefully the index is still around so peoples scripts carry on working.

I personally use “git rebase -i” and “git add -p” more when trying to get a nice patch series. I often frowned that I couldnt do this in Bazaar, then found out I could. I like using bzr looms so that I can version the patches too, i believe this is similar to topgit but havent any experience with that.

You can use bzr’s shelf (stash) to emulate the index, and i expect a more natural way of doing this in future releases.

And if your task is formatting nice patches, rather than dumping it all in a version control system, the index is a great tool. I personally consider the index a fantastic feature (and I am sure lots of git users will agree). Not being able to do these kinds of in bzr is a horrible mistake to me.

So depending on what your point of view is, the other system is a mistake. Just don’t assume everybody thinks like that, unless you have the numbers to prove it.

Also, git’s UI mistakes are still myriad and aren’t going away. Calling the index the index is still foul and will never change, git add as modifying the index is still stupid and will never change now, etc etc… and really, I’ve tried hacking on git’s UI, the code is so horrible and convoluted that its near impossible to fix things like the user-incomprehensible error messages that still come out.

I look forward to when Git reaches “2.6″ status (hopefully with an LGPL library backend to it), but anyway..

The main point i’m saying is: If we can support Bzr and Git without crippling anyone like git-svn does, why don’t we. Then I don’t really care about which one is the one we tell people to use.

Why does it matter to the Git people if we don’t exclude the Bazaar people? You wouldn’t get away with only accepting patches from Vim users, would you? (I’m waiting for someone to flame that..)

People worried about the mapping should just wait for me to get to alpha, then we can see People worried about the speed needn’t.

The argument at the time was more along the lines of:
* git’s UI is dire
* git still lacks a few features, though has a very active development base
* bzr is unusably slow and the repository size is ludicrous, though it also has a very active development base and a well-documented UI
* git makes too many mistakes that remind you of tla[0]
* interesting projects in mercurial, darcs, codeville, rosegarden, etc; though they couldn’t really be taken seriously in themselves, it was something to watch as new systems could build upon existing implementations (e.g. bzr building on darcs and tla/baz as well as its own design from mbp’s work)

If we were having that argument today, it would look like:
* git is still the speed king
* git’s remaining UI mistakes (mainly forcing people to care about the index: -a as default kthx) are too small to really matter, well-documented, and will probably disappear soon; for a basic operational cheat sheet, bzr and git are today equally usable
* git still produces vastly smaller repositories than the competition, and bzr still don’t seem to have a coherent repository story (though this may have changed in the past few months) and guarantee of both forward- and backward-portable formats
* more projects seem to have adopted git than bzr, with bzr probably getting more initial interest but git really picking up and moving up the stack in 2008 (and hey, git -> ruby -> gospel, right?)
* no-one cares about anything other than git or bzr, and the rush of new VCSes has settled down

So it’d be a clear winner and we’d switch with no protest, although our development for the last two and a half years would’ve been crippled compared to what we’ve enjoyed since then.

[0]: Except that the designers aren’t idiots and thus the short-sighted crap (the implementation is the only sensible UI, users find revision control fundamentally interesting, porcelains will save us from our godawful UI) was eventually beaten out.

Show us the code

The bzr repo format doesnt matter so much – svn also has changed its format and svn.gnome.org has been upgraded to use smaller more featureful formats. For our server side, the the size doesnt matter so much. We are going to save on space over SVN. (Note: This claim is based on an older version of SVN, my local SVN mirror of svn.gnome.org hasnt been upgraded to 1.5).

So let me just explain an important part of the idea again. Git doesnt care about how the data is stored on a remote server, so long as it can exchange pack files when pushing and pulling. Pretty much for full Git history to be preserved we just need to store committer, author, commit message, timestamp. list of parents, list of files and raw file “blobs”. Theres no complicated metadata to mangle from one format and back again. Its easier than syncing your mobile phone to linux. NO features of Git are harmed in the making of this walnut flavoured ice sculpture.

By putting this mapping on the server side we also need to make no attempt to represent Bazaar metadata in Git format. The git repositories will be “pristine”.

Thank you for your polite comment, its very refreshing. I’d be interested in replying to any other further (specific) concerns you have over this. You comment, “That way, users using either can benefit from whatever suits them best.”. This makes me think we both want the users to have choice, so i’m uncertain why you disagree (the only other options open to GNOME right now WILL lessen my choices).