[collyw]

I appreciate that git is powerful, but should we really need to read a book just to get the best from a source control system? It seems overly complex to me at times (any time I do anything outside of my usual workflow).

Version control only makes up a part of the whole development process, and plenty of coders out there manage without any at all.

[oneandoneis2]

IME the main thing that makes git so hard to understand is the determination to think of it as "distributed subversion" - I find it substantially easier to teach git to people who've never used a VCS before than to people who have years of experience with SVN/CVS/etc.

It can seem a complicated nightmare until you grok how it really works. And if you have preconceptions getting in your way, yes, a book can be a very useful tool to give you that "Aha!" moment.

Once you stop someone thinking "It's a log of patches" and make them understand "It's like VM snapshots logged in a linked list" all the weird difficult stuff just Makes Sense.

[mschaef]

How do you expect things to work? This expectation that complex tools should be so obvious that they can be used without a book seems pretty odd to me. There aren't many other serious engineering disciplines where people enter it with that kind of mindset.

The source code for a system is one of the more valuable assets produced by a software development team, and managing source code is heavily about managing risk. Losing source code means losing work (money and time). Deploying source code too early means exposing the users of your system to code that might not be adequately tested. In distributed development, accepting unsigned patches means that your system might include untrustworthy code... the list goes on and on.

Part of the reason that git is complex (and this can be said about any serious source code management system) is that it solves complex problems. Fifteen years ago, Jamie Zawinski said this about Mozilla... I think it's also true for git:

"Convenient though it would be if it were true, Mozilla is not big because it's full of useless crap. Mozilla is big because your needs are big. Your needs are big because the Internet is big. "

-- http://www.jwz.org/doc/easter-eggs.html

[alwillis]

Yes, Git is powerful, but it’s not the only open source, distributed version control system out there. Google’s comparison between Git and Mercurial is worth reading: https://code.google.com/p/support/wiki/DVCSAnalysis

[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.)