When you have hundreds of people simultaneously patching 25000 files of the Linux Kernel in sometimes conflicting ways, you might need some scheme or plan to sort all that out before you can build your next kernel and reboot.

The Linux team uses "git" for their source code repository management, a homegrown solution that is optimized for highly distributed development, working with huge sets of files, merging independent work at multiple levels, and seeing who broke what. (Git has also since been notably adopted by the Cairo, x.org, and Wine teams, and is being transitioned to by the Mozilla codebase.)

In my talk, I describe what "git"; is and isn't, and why you should use it instead of CVS, Subversion, SVK, Arch, Darcs, Mercurial, Monotone, Bazaar, and just about every other repository manager. I'll also walk though the basic concepts so that the manpages might start making sense. If I have time, I'll even do a live walkthrough, where you can watch how fast I make typos.