Git for Ages 4 and Up

[jducoeur]

The Querki project (assuming it happens) is going to be Scala-based -- and Scala, by and large, runs on Git. So it seems like time for me to start understanding how Git works.

(This is very much a hardcore-programmer thing -- the rest of you should skip over it. For the programmers not familiar with it, Git is the currently-hot source-control system, which has been moving in and taking over the open-source world in recent years, gradually supplanting Subversion in some circles. Most Scala development is Git-based these days, and github is the most common hosting service of choice.)

Anyway, the question has been how to get started. So I was gratified to come across this presentatiion on the internals of Git. It's a 45 minute video, clearly a recorded session from a conference. It describes how Git thinks, using Tinkertoys to demystify the process. (On the grounds that nothing demonstrated with Tinkertoys can possibly be intimidating, and that they are the perfect tool for illustrating directed acyclic graphs.)

A caveat or two are in order. This is a session on Git internals, so you can understand what's going on. It goes into no depth on the commands, and it very casually assumes that you know your way around the concepts of source control -- it's very much Git for the experienced Subversion (or suchlike) user. And it has a live demo of the relevant Git commands running while they're showing the Tinkertoys, and that goes about as well as any live demo ever does -- there are several "Hmm. It's not supposed to do that" moments.

That said, it's a fine presentation: reasonably clear and light-hearted while giving some crucial technical meat. He does manage to give a number of key concepts very quickly, and I like what I see -- Git's fundamental assumptions (immutability, a principle that disk space is cheap but network lag is expensive, and so on) really appeal to me. So I feel better now about the likelihood of hosting Querki's source code on github, with the rest of the Scala world.

(Extra credit: another tool I've come across as I got the OP Compiler project up and running is giter8, a Scala tool to make it dead-easy to get projects started. Basically, giter8 lets you develop "template" starter projects, and distribute them with zero effort. It makes it a single command to fetch and install one of these projects. Scala Typesafe uses it for their tutorials, and they are a truly great innovation -- fastest path to getting started I've come across yet...)

Comments

[zachkessin.livejournal.com]

I am a big fan of git, the one place that the git community kind of falls short is that with a VCS like SVN there is really only one workflow you can have. Everyone commits to a central repo and thats it.

With git there are a LOT of ways you can do things a lot of ways. Everyone can just access one central repo but you can organize your team in a bunch of other ways as each GIT repo is a full peer and can talk to any other repo. So you can do cool things like send a set of commits directly to another developer if say you want them to review a change set.

Its also nice in that you can commit a bunch of changes without exposing them to everyone else so you can commit in progress code without having to integrate it yet.

All of this also applies to Mercurial (hg) as well

[metahacker.livejournal.com]

Git has many great features, and having everything on disk--no db needed--is, I feel, a key one.

As mentioned above, decentralizing allows an entirely new set of ways of working, many of which you simply might not *need*. But there are setups where, e.g., you push things to a particular repo when you want them to be automatically qualified, or to another one for release, or whatnot. You can have nests of repos on different (or the same!) server for different purposes, and move code between them freely. IN a corporate environment, though, this drives people nuts ("but where IS the code? is it ready for release?").

I also like the "put a repo anywhere" pattern. I have one on my thumbdrive, as a way of transporting things when I don't have network without having to worry about version safety or losing things. If I would, the merge will tell me...

I think once you understand the staging area, and how you have to "do everything twice" (e.g., git add, then git commit -- though of course there's git commit -a), then you're 80% of the way to understanding git. At least until you get into rewriting history, which is fun.

But there's an awful lot in there, and it's changing every day--I only recently found git commit --amend, which is a wonderful shortcut for something that used to be annoying ('oops, should have committed this too').

[ilaine-dcmrn.livejournal.com]

I've been debating if I should move from subversion to git without sufficient information. Thanks for the link.

[jducoeur]

Happy to. My impression is that Git's killer app is distributed development, and from the architecture you can see why, but in general I think it's got a good attitude, if one a bit foreign to many IT mindsets. (In that it cares more about synchronization than where the "official" repo is.)

[hudebnik.livejournal.com]

I set up a department svn server and have used it for my textbook and a few of the students in a senior-project course, but it's a hassle: the IT people won't let me set up a server that's visible from off-campus, so when my students or I want to use it from home, we need to go through an ssh tunnel. And it's a pain having to administer user accounts on a central server, so decentralized revision control has a certain appeal.

A few years ago I joined an open-source project (Racket) that uses git, so I've had to learn a little of it. It is a different mental model than svn -- you add things, then commit them, then push them or request a pull -- but it seems to do the job nicely.

I'm trying to figure out how to teach revision control in an undergrad class (probably fitting it into either first-year programming or the sophomore-level Unix class). Mercurial has beginner-friendly plugins for Windows and some of the popular IDE's, so that's a point in its favor (most of our lab classrooms are all-Windows, alas). Helpful suggestions welcome.

Very nice explanation

[andy hendrickson (from livejournal.com)]

Thanks!

I've been using git for a couple of years, but never really understood what was going on under the hood. This clears up a lot.

Andy