[egil]

Git was originally created to manage the Linux kernel. It is indeed complex, but it has to be at that scale. Git might not be the best option for every project, but I find it quite easy to use at the trivial scale as well. (How do you beat 'git init' ? No repository setup or anything.)

[ams6110]

I'm not so convinced. Other OSes manage with more "primitive" tools. OpenBSD still use CVS.

[Crito]

The BSDs use massive monolithic repos that would be difficult to move entirely over to git. Instead of putting separate projects in separate repos, they consider all of their different projects to actually be "one project". These ludicrously massive repos have no business being in git; they would need to restructure their projects to effectively migrate.

This is not a scheme that should be emulated. Compartmentalization/modularization is not only useful at the micro-level in code, all of it's benefits are available when applied at a project/organization level.

For another point of view, consider this page: https://wiki.freebsd.org/GitDrawbacks I think nearly everything on that page is misleaded/misleading, or flat out incorrect, and they failed to identify the technical limitations with git that would apply to them. Other viewpoints are nevertheless useful.

(Actually the BSDs use a handful of massive monolith repos, but that is just nitpicking/)

(Disclosure, I work at a company that uses git at a _much_ larger scale than the BSDs use CVS. Many many times larger than all the OpenBSD repos combined (http://www.openbsd.org/cvsync.html). The trick? We don't have a handful of repos for the company, we have a handful of repos for each team. Each project gets it's own repo. Our build systems, deployment systems, and dev environments are tooled for this. One of the things it even allows is different teams using different VCS, if you're on a team with a bunch of luddites you can still use SVN for your code, and you will be able to build against other code and other code will still be able to build against yours.)

[dspillett]

As did Linux before Git, but Linus and the core team around him were finding the process getting too cumbersome and bottlenecked. Linus "scratched the itch" and produced git both specifically to fill that set of needs and with the intention of it being generally useful for other projects they were concerned with.

OpenBSD's kernel development is presumably run differently (IIRC there is a much smaller number of people trying to directly feed into it for a start, which was a key problem with Linux at least at the time Git was birthed) so processes and tools that fit their needs will look different. Either they haven't had enough trouble with the older tools/processes that the effort of an infrastructure change is worth sinking time into, or they have other concerns with the alternatives (security, as someone has mentioned above, and code maturity concerns may be involved, though the latter much less now as it has been pretty solid for some time), or maybe they intend to move but just haven't decided on an alternative yet.

[woadwarrior01]

Linux was using BitKeeper, a commercial DVCS. The raison d'etre for git was because the company behind BitKeeper revoked the license for the Linux guys to use it. http://en.wikipedia.org/wiki/BitKeeper

[dspillett]

Ah, I forgot that step.

They moved to a DVCS to solve some of the workflow issues, then Linus created git in large part because of the licensing issues.

Another detail missed in my previous post: If I remember rightly there were a couple of F/OSS DVCS's in development at the time, but he chose to write his own as some of them were not yet near stable and the others didn't quite work the way he wanted. I dimly recall some criticism for choosing a commercial product prior to git, and that decision was for much the same reasons git was created instead of using one of the other available options.

[BugBrother]

Isn't OpenBSD a special case? Most really security conscious organizations seem to use outdated tools, because the new tools haven't been vetted/verified/etc yet.

(That is one reason I stay away from security work. The theory is fascinating, but the practice is just not fun.)