Subject: Re: [boost] [git] Mercurial?
From: Julian Gonggrijp (j.gonggrijp_at_[hidden])
Date: 2012-03-20 07:03:57
To be honest I'm a bit wary of this discussion, but I think some
important arguments are overlooked while other, less important
arguments are being exaggerated.
Thomas Heller wrote:
> Let me try to wrap my head around all this...
> So essentially, the argument is to choose git over whatever is because of its marketshare, right?
I don't think this is the only argument, but you do agree that
marketshare can make a difference, right?
> The only reason behind this i can think of is to attract new boost contributors [...]
> Ok, I can see that as a possible advantage for git. Especially since a lot of people expressed themselves that svn is _the_ major blocker for not contributing.
> So far so good, this is the argument for people already familiar with git. Let's check the statistics again:
This is a false comparison. The first line on boost.org is literally
"Boost provides free peer-reviewed portable C++ source libraries".
even Intercal bindings. Using any kind of VCS, on the other hand, is
a means to the end of producing free peer-reviewed portable C++
> So, what about persons who are infected by their favorite poison and have to learn the VCS tool of choice. I keep reading about git having a steep learning curve, so maybe we won't attract those developers either ...
I really don't see why there's such a fuss about git having a steep
learning curve. Basic usage of git isn't any harder than basic usage
of svn -- or probably any other VCS; you always need to cover about
eight commands, two configuration files and a bunch of options.
People tend to learn only basic usage at first (whatever VCS they're
learning) and the more advanced stuff is only covered when we feel we
need it. Perhaps the learning curve is steep if you want to become a
black belt git master, but that's irrelevant for most Boost
Basic usage of git is different from basic usage of svn in some
crucial aspects, but similar enough for anyone to be able to adjust
even if you don't like it. It can definitely be learnt within a day.
Why don't you just give it a try? It never hurts to learn something
> I'd argue that writing code is not done in the VCS. Be it writing a patch for an existing software or a completely new library. The complexity is in writing the code itself. Or applying the patch and verify it.
I think I'm missing your point here. Is it just an aside, or did you
mean to argue for or against a particular VCS?
> FWIW, I am the last person who will oppose such a change.
> But currently, noone presented a fair reasoning in favor for git,
Well, allow me to present some fair reasoning to you.
With regard to git versus svn: I think enough fair reasons have been
given why git (or a DVCS in general) is better than svn. I'm not
going to repeat those arguments here.
With regard to git versus mercurial: given that it's probably a good
idea to switch to a DVCS, git and mercurial seem to be the primary
candidates. I think everyone in this thread should be more willing to
admit that they're close competitors. In many ways they're about
equally "good", and when they aren't the differences are quite moot:
- mercurial has native support for Windows, but git is also fairly
well supported on Windows and seems to be rapidly improving;
- git allows you to edit history while mercurial doesn't, but which
you like better is a matter of preference;
- they seem to treat heads and branches differently, but again that
appears to be mostly a matter of preference;
- git seems to be more "powerful" and less susceptible to errors,
while mercurial is said to have better documentation -- while this
doesn't make either objectively better than the other in the first
place, they're also both catching up on their weaker side;
- they are built with very different architectures (many executables
written in C versus a monolithic program in Python), but in the end
both work well enough and both seem extensible enough for most
At this point one could say that it doesn't matter whether we pick
git or mercurial, as long as we actually do it and move away from svn
(preferably as soon as possible). However, as far as popularity and
enthousiasm is concerned git seems to win:
- Within the existing Boost community, git seems to be more popular
than mercurial. I've seen several library proposals pass by that
were versioned with git. I'm also sure that at least one existing
Boost library is being maintained in a GitHub repository. AFAICT
mercurial scores a solid zero on both of those.
- A lot of work has already been done in order to transition Boost
from svn to git. From what I read in the "neglected aspects"
thread, John Wiegley's subconvert tool seems to be almost ready and
that also seems to be the last (only?) thing we need in order to
switch. For mercurial no work has been done yet.
- Git is also more popular than mercurial outside Boost. Like it or
not, this simply means that git is a better bet.
> or how such a transition could be done.
To me, that doesn't seem like a hard problem. With some more thought
one could probably produce a more robust plan, but basically I think
it would be something like this:
1. Finish the subconvert tool.
2. Verify that everything builds and that all unit tests run as
3. Give library maintainers a grace period in which they can switch
development from svn to git. Keep syncing with subconvert in the
4. Once all libraries have transitioned, we can probably establish
that the switch was successful and abandon the svn repository.
> [...] Somehow people tend to forget in their Git crusade that other people didn't go through the transition yet, and are searching for arguments to actually make such a change.
Here's an argument for just learning the basics of git: most people
who tried both svn and git seem to agree that git is sufficiently
better than svn to make the switch. Surely you want to have a look?
I recommend that you try the tutorial at http://gitimmersion.com/ .
It doesn't have to take much of your time.
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk