Well the evidence is hard ... but let me try to replay my experience. I am sure, the next guy will step up and tell me that i did it totally wrong (actually happened when i tried to collaborate on said project using git).
So, the journey starts about a year ago or so. I decided i need to check out this new project i heard about. I was (actually still am) very determined to contribute to that project, so i cloned the repository, browsed the code etc. eventually i decided to fork this project cause i wanted to get some hacking done. That is what i did. Then life happened and i had to postpone the work on the project. A few months later, I got a new assignment to contribute a module for that project. Remember, i still got that (public) fork lying around. So i tried to get it up to date. First bummer. I don't remember which commands i tried in which order, but merge didn't really work, and i messed up during rebase. the result was, that i spent an entire day trying to figure out how to get this outdated fork uptodate to start hacking again. Also, since trying to learn this new git tool and its cool branches and stuff, i had of course multiple local branches lying around, never really figured how to properly maintain that (origin branch, master fork branch, origin feature branch1, etc. ...) and constantly pushed to the wrong branches and/or repos (luckily, I didn't have any write rights to the repository i forked from). And not to forget that i wanted to try some feature X from branch Y, but needed to combine that with my feature Z on branch U. Essentially, whenever I tried to publicly show my progress to someone, I ended up totally confused, and in a complete local litter box of branches, where half of them didn't really do what they were supposed to (like remote tracking). I needed to search the internets for how to accomplish task X that wasn't a simple "git add" or "git commit". Asking people after i didn't know any further lead to the answer that i shouldn't have executed command X in the first place. D'oh, that was how i read it on the internets ... I am sorry, this isn't a really detailed usage story, missing all the commands etc. that is why I wasn't clearer in the first place. To be perfectly honest, i even forgot most of the git usage i learned back then. I hope you can still relate a little to what I am talking about.
But yeah ... this is the memory that makes me arguing against git. Also, it is the reason why i argue against all those "advantages" people see over using git. I clearly fail to see them cause i miserably failed in actually trying to use them.
My $0.02 ...
P.S.: In this case, the usage of git actually prevented me to make the contribution i wanted to do. Nevertheless I was able to contribute a tiny bit. But well ...
Thanks a lot! My first thought here is: It's all about the mental concepts! Just a little, perhaps commonly understandable, example before coming to Git etc.: Starting with C++, I found it fascinating (especially templates), and at the beginning it was all hard work --- but at some point things started to flow, I got an intuitive feeling for it, and could just "write" code (with templates). That's an example for the mental concepts, or perhaps "mental images", mental maps, I'm referring to, and which one needs to work (live). Also a disclosure: I personally use Git all over the place, private projects, software projects, university work, and I am very satisfied with it. In the same sense, it flows, things work out (mostly) as expected, it helps me a lot. Compared to what you describe above, I am perhaps a more conservative user --- if I really want to use a new feature, I better create some experimental repositories first, make experiments, until I start being able to predict what should happen. It has been said that Mercurial and Git aren't that different: I think in a certain sense that's true, but then, more fundamentally, it's very misleading. Branching and the understanding of what is "history" are such complicated concepts (inherently!), that the differences crucially matter, make a big difference, when it comes to the point that you want to do more complicated things, and this in a *comfortable* way (that you (intuitively) know what you are doing). Unfortunately in the whole literature on computing (and also mathematics; sometimes computer science is a bit better, at least wants to do things better) little attention is on concepts: a stream of commands / actions is shown to you, and from that you are supposed to learn something. The Internet is great for technical details (amazing StackOverflow and related sides), but when it comes to greater pictures, the underlying world models, there is not much (though, again, on StackOverflow there is some help). It would be a great thing if Boost could come up with "best practice", mental maps, advice and role models how to do the standard actions required to work with Git (w.r.t. Boost). If you really jump into the complexity of the world of SCM, which Git I believe offers you, without careful preparations, huhuhu, if I may say, there you go and the sharks are waiting. You can branch, stash, sub-something, remote here and there, a bit of history surgery, and this all at once, all mixed together ... And there are also practical problems: you mention pushing to the wrong branches --- this can happen, and one has to develop a certain discipline to avoid that. Before starting to work, "git status" on the command line, or rescanning with git-gui is a must. So, to conclude, I believe that if Boost provides workflow models, with general explanations and examples how to do it (command-line *and* git-gui+gitk would be great --- git-gui and gitk are such a great help, but they are overlooked so often), for the common actions, and there is a bit of culture to sustain these efforts, expand and improve it, then Git will be a great tool for Boost. (There is, of course, a little devil in Git, the seduction by all these possibilities, and a bit care is needed.) Oliver