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: https://github.com/languages Right ... so many potential new developers ... Maybe we should provide Javascript bindings ...
This is a false comparison. The first line on boost.org is literally "Boost provides free peer-reviewed portable C++ source libraries". So it's not among the goals of Boost to provide Java, JavaScript or 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++ source libraries.
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 developers. 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 new.
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 purposes. 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 expected. 3. Give library maintainers a grace period in which they can switch development from svn to git. Keep syncing with subconvert in the meanwhile. 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. -Julian