Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

kfogel writes "Two thumbs up, and maybe a tentacle too, on Version Control with Git, 2nd Edition by Jon Loeliger and Matthew McCullough. If you are a working programmer who wants to learn more about Git, particularly a programmer familiar with a Unix-based development environment, then this is the book for you, hands down (tentacles down too, please)." Read below for the rest of Karl's review.

Version Control with Git, 2nd Edition

author

Jon Loeliger, Matthew McCullough

pages

456

publisher

O'Reilly Media

rating

Very good.

reviewer

Karl Fogel

ISBN

978-1-4493-1638-9

summary

Using the Git version control system for collaborative programming.

There's a catch. You have to read the book straight through, from front to back. If you try to skip around, or just read the parts you feel you need, you'll probably be frustrated, because — exaggerating, but only slightly — every part of the book is linked to every other part. Perhaps if you're already expert in Git and merely want a quick reminder about something, it would work, but in that case you're more likely to do a web search anyway. For the rest of us, taking the medicine straight and for the full course is the only way. To some degree, this may have been forced on the authors by Git's inherent complexity and the interdependency of its basic concepts, but it does make this book unusual among technical guides. A common first use case, cloning a repository from somewhere else, isn't even covered until Chapter 12, because understanding what cloning really means requires so much background.

Like most readers, I'm an everyday user of Git but not at all an expert. Even this everyday use is enough to make me appreciate the scale of the task faced by the authors. On more than one occasion, frustrated by some idiosyncrasy, I've cursed that Git is a terrific engine surrounded by a cloud of bad decisions. The authors might not put it quite so strongly, but they clearly recognize Git's inconsistencies (the footnote on p. 47 is one vicarious acknowledgment) and they gamely enter the ring anyway. As with wrestling a bear, the question is not "Did they win?" but "How long did they last?"

For the most part, they more than hold their own. You can sometimes sense their struggle over how to present the information, and one of the book's weaknesses is a tendency to fall too quickly into implementation-driven presentation after a basic concept has been introduced. The explanation of cloning on p. 197 is one example: the jump from the basics to Git-specific terminology and repository details is abrupt, and forces the reader to either mentally cache terms and references in hope of later resolution, or to go back and look up a technical detail that was introduced many pages ago and is suddenly relevant again[1]. On the other hand, it is one of the virtues of the book that these checks can almost always be cashed: the authors accumulate unusual amounts of presentational debt as they go (in some cases unnecessarily), but if you're willing to maintain the ledger in your head, it all gets repaid in the end. Your questions will generally be answered[2], just not in the order nor at the time you had them. This isn't a book you can read for relaxation; give it your whole mind and you shall receive enlightenment in due proportion.

The book begins with a few relatively light chapters on the history of Git and on basic installation and local usage, all of which are good, but in a sense its real start is Chapters 4-6, which cover basic concepts, the Git "index" (staging area), and commits. These chapters, especially Chapter 4, are essentially a design overview of Git, and they go deep enough that you could probably re-implement much of Git based just on them. It requires a leap of faith to believe that all this material will be needed throughout the rest of the book, but it will, and you shouldn't move on until you feel secure with everything there.

From that point on, the book is at its best, giving in-depth explanations of well-bounded areas of Git's functionality. The chapter on git diff tells you everything you need to know, starting with an excellent overview and then presenting the details in a well-thought-out order, including an especially good annotated running example starting on p. 112. Similarly, the branching and merging chapters ensure that you will come out understanding how branches are central to Git and how to handle them, and the explanations build well on earlier material about Git's internal structure, how commit objects are stored, etc. (Somewhere around p. 227 my eyes finally glazed over in the material about manipulating tracking branches: I thought "if I ever need this, I know where to find it". Everyone will probably have that reaction at various points in the book, and the authors seem to have segregated some material with that in mind.) The chapter-level discussions on how to use Git with Subversion repositories, on the git stash command, on using GitHub, and especially on different strategies for assembling multi-source projects using Git, are all well done and don't shirk on examples nor on technical detail. Given the huge topic space the authors had to choose from, their prioritizations are intelligently made and obviously reflective of long experience using Git.

Another strength is the well-placed tips throughout the book. These are sometimes indented and marked with the (oddly ominous, or is that just me?) O'Reilly paw print tip graphic, and sometimes given in-line. Somehow the tips always seem to land right where you're most likely to be thinking "I wish there were a way to do X"; again, this must be due to the author's experience using Git in the real world, and readers who use Git on a daily basis will appreciate it. The explanation of --assume-unchanged on p. 382 appeared almost telepathically just as I was about to ask how to do that, for example. Furthermore, everything they saved for the "Advanced Manipulations" and "Tips, Tricks, and Techniques" chapters is likely to be useful at some point. Even if you don't remember the details of every tip, you'll remember that it was there, and know to go looking for it later when you need it (so it might be good to get an electronic copy of the book).

If there's a serious complaint to be made, it's that with a bit more attention the mental burden on the reader could have been reduced in many places. To pick a random example, in the "Branches" chapter on p. 90, the term "topic branch" is defined for the first time, but it was already used in passing on p. 68 (with what seems to be an assumption that the reader already knew the term) and again on pp. 80-81 (this time compounding the confusion with an example branch named "topic"). There are many similar instances of avoidable presentational debt; usually they are only distractions rather than genuine impediments to understanding, but they make the book more work than it needs to be. There are also sometimes ambiguous or not-quite-precise-enough statements that will cause the alert reader — which is the only kind this book really serves — to pause and have to work out what the authors must have meant (a couple of examples: "Git does not track file or directory names" on p. 34, or the business about patch line counts at the top of p. 359). Again, these can usually be resolved quickly, or ignored, without damage to overall understanding, but things would go a little bit more smoothly had they been worded differently.

Starting around p. 244 is a philosophical section that I found less satisfying than the technical material. It makes sense to discuss the distinction between committing and publishing, the idea that there are multiple valid histories, and the idea that the "central" repository is purely a social construct. But at some point the discussion starts to veer into being a different book, one about patterns for using Git to manage multi-developer projects and about software development generally, before eventually veering back. Such material could be helpful, but then it might have been better to offer a shallower overview of more patterns, rather than a tentative dive into the "Maintainer/Developer" pattern, which is privileged here beyond its actual prominence in software development. (This is perhaps a consequence of the flagship Git project, the Linux kernel, happening to use that pattern — but Linux is unusual in many ways, not just that one.)

The discussion of forking and of the term "fork", first from p. 259 and reiterated from p. 392, is confusing in several ways. It first uses the term as though it has no historical baggage, then later takes that historical baggage for granted, then finally describes the baggage but misunderstands it by failing to distinguish clearly between a social fork (a group of developers trying to persuade users and other developers to abandon one version and join another), which is a major event, and a feature fork (that is, a branch that happens to be in another repository), which is a non-event and which is all that sites like GitHub mean by forking. The two concepts are very different; to conflate them just because the word "fork" is now used for both is thinking with words, and doesn't help the reader understand what's going on. I raise this example in particular because I was surprised that the authors who had written so eloquently about the significance of social conventions elsewhere would give such an unsatisfactory explanation of this one.

Somewhat surprisingly, the authors don't review or even mention the many sources of online help about Git, such as the #git IRC channel at Freenode, the user discussion groups, wikis, etc. While most users can probably find those things quickly with a web search, it would have been good to point out their existence and maybe make some recommendations. Also, the book only covers installation of Git on GNU/Linux and MS Windows systems, with no explicit instructions for Mac OS X, the *BSD family, etc (however, the authors acknowledge this and rightly point out that the differences among Unix variants are not likely to be a showstopper for anyone).

But this is all carping. The book's weaknesses are minor, its strengths major. Any book on so complicated a topic is bound to cause disagreements about presentation strategy and even about philosophical questions. The authors write well, they must have done cubic parsecs of command testing to make sure their examples were correct, they respect the reader enough to dive deeply into technical details when the details are called for, and they take care to describe the practical scenarios in which a given feature is most likely to be useful. Its occasional organizational issues notwithstanding, this book is exactly what is needed by the everyday Git user who wants to know more — and is willing to put in the effort required to get there. I will be using my copy for a long time.

Footnotes

[1] One of my favorite instances of this happened with the term "fast-forward". It was introduced on p. 140, discussed a little but with no mention of a "safety check", then not used again until page 202, which says: "If present, the plus sign indicates that the normal fast-forward safety check will not be performed during the transfer." If your memory is as bad as mine, you might at that point have felt like you were suddenly reading the owner's manual for an early digital wristwatch circa 1976.

[2] Though not absolutely always: one of the few completely dangling references in the book is to "smudge/clean filters" on p. 294. At first I thought it must be a general computer science term that I didn't know, but it appears to be Git-specific terminology. Happy Googling.

[3] (This is relegated to a floating footnote because it's probably not relevant to most readers.) The book discusses other version control systems a bit, for historical perspective, and is not as factually careful about them as it is about Git. I've been a developer on both CVS and Subversion, so the various incorrect assertions, especially about Subversion, jumped out at me (pp. 2-3, p. 120, pp. 319-320). Again, this shouldn't matter for the intended audience. Don't come to this book to learn about Subversion; definitely come to it to learn about Git.

[4] As long as we're having floating footnotes, here's a footnote about a footnote: on p. 337, why not just say "Voltaire"?

[5] Finally, I categorically deny accusations that I gave a positive review solely because at least one of the authors is a fellow Emacs fanatic (p. 359, footnote). But it didn't hurt.

For those who don't know what I'm talking about, click on the author link. I wouldn't normally know whether to trust a review, but a steganographic kitten photo placement service? I think we can safely assume that the author of the review is a legitimate geek whose opinion can be trusted.

I wouldn't normally know whether to trust a review, but a steganographic kitten photo placement service? I think we can safely assume that the author of the review is a legitimate geek whose opinion can be trusted.

I guess you did not inspect the link to his steganographic kitten service (unless you're on a deeper level than I am:)

cloning a repository from somewhere else, isn't even covered until Chapter 12, because understanding what cloning really means requires so much background

That's... that's... just... what?

Cloning is part of the brutally simple (and amazingly flexible) guts of git. Given Linus's hatred of C++ I think what git has become is deliciously ironic, but the basics could not be easier to understand.

Do you know if it has any sort of mechanism for holding submits until approved? We're currently using Subversion and the general consensus on that one is giving everyone their own dev branch, then having the overseer handle merging, which is tolerable for some small number of developers.

You have complete control over what goes into your repository. Off the top of my head, I'd have a repository for submitters to push to and another one only you have write access to, into which you can pull anything you want and which you can all agree to call the "official" repository of approved commits.

Nowhere is it written developer branches must be pushed anywhere. What goes on in their own repos is really nobody else's business, because see above: nobody has to take or keep anything they don't want. Do take the time to learn how the object db, blobs and trees and commits, is structured, and the thumbs into that db. If you're like me, once you see it you'll have the itch to dink with the innards with shell commands just because it's so ridiculously easy. Build from there until you understand the low-level commands, and after that you'll see all the rest as merely conveniences for common tasks, which is what they are. For my money, any other route to understanding git is like trying to learn math without understanding equality.

The only thing I think painful about it is all of the freaking URLs you have to use all over the place.. Then again, I'm comparing it to the mostly easier cvsâ¦ and from a currently non-git user point of view, you go from rev #s in cvs to big URLs in svn to completely incomprehensible long hex #s in git. But at least I seem to have fewer merge conflicts with svn than I do with cvs.

Recently as in when? I've been using svn for at LEAST a few years, and it's been the same as long as I've been using it.

svn merge -c NUM URLis what I use the vast majority of the time.

I still don't know what you mean by "painful", unless it means merge conflicts.. and as I said in my original reply, at least anecdotally, I saw merge conflicts far less often in svn than cvsâ¦ and I say this as someone who prefers cvs.

Other source control systems parse the code to detect methods that have moved around. This makes merging even easier, since if all you did was move a method, or add some whitespace, it will notice that it's not really a conflict. Th

You haven't been using it long enough so. There was a point in time were svn supported using merge but failed to record any information about what had been merged to where. So if your repeated the operation, you got a giant clusterphuck of a result. Same thing applied to subsequent merges, since there was no information stored in subversion you had to know beforehand which revisions were previously merged.

The consequence of this was that many teams ended up having to create custom tools to perform the mer

Gerrit is a code-review tool for git -- you submit your changes to gerrit, it holds them until they are code reviewed and approved, then they get passed into the central repo. You can configure it so that one person (or a small subset) is a required gatekeeper for passing things to the central repo, or so that it requires some number of "yes" votes from reviewers to be approved.

It gives a very nice web front end for diffs and comments when doing code reviews, t

Yeah, don't pull them into your branch! It takes a bit to get used to, but your brain gets knocked straight eventually;)

Seriously though, ENORMOUS projects with thousands of submitters are using Git effectively. Most of the larger projects use a "lieutenant" based system where the head of the project has several trusted sources that he/she pulls from. The lieutenants are able to divide up the pull requests and each test/integrate a portion.

Just give every developer their own *repo*, which only they have commit rights to. It can be centrally stored on a honking great central server with a reference repo if you have loads of developers, and you're worried about space. (Of course, they can do their day-to-day work on their own repos on their own desktops/laptops if they'd rather work with a local copy, distributed vcs's are designed to be flexible that way.)Each coherent change (one feature, one bugfix, one update) should be on a branch in their

Given Linus's hatred of C++ I think what git has become is deliciously ironic,

Huh? How is that ironic? Linus is a very good C programmer who has some very ignorant and very silly ideas about C++. He probably could have written an excellent VCS in asm. Wouldn't stop it being a bloody stupid idea, though.

Actually I think he was dead on target about the need to keep the hordes away from critical code.

The irony I see is in how complicated people make git seem by not religiously focusing on its core, only using the higher-level abstractions and conveniences to add lasting value, when really do eliminate endless petty little error-prone tasks now or in the future -- say with a straight face that the need for rerere is any less abstruse or rare than for template name binding or partial specialization, I dare

I am reading it now, and I would probably be having a much harder time if I hadn't read Pro Git first (available online gratis). I'm thinking specifically of the concept of branches and HEAD being pointers to commits. I do appreciate the thoroughness of this book, though.

Does the book discuss my favorite workflow automation, git-flow? Other than in the obvious sense, like fundamentally "git flow feature finish 2012-11-26-whatever" basically just runs 3 to 6 git commands on the 2012-11-26-whatever branch and the develop branch although I can't be bothered to remember which commands exactly?

:( You need about 5 pages of material to learn how to do 90% of stuff in GIT, it gets more complicated in bigger environments, but a lot of it is rinse & repeat. The best I've done with GIT is pair it up with NANT/CruiseControl.NET to get a free & extremely effective build server going. Most of the setup was in the latter two technologies referencing dev & prod environments. A 456 page book about this straight forward of a technology seems a bit excessive. Then again 456 pages is probably an

This seems to be a common response to complaints about git, in spite of it being obviously silly. If more people get confused: it is harder to use; that is what harder to use means.

Other flavors of such silliness include:"git is not complex, you just have to understand its internal data model well" or "it is great, just read this 450 page book very very carefully and perhaps you can figure it out"

VSS was at least usable if you stuck SourceOffSite in front of it. That kept 99% of the problems from happening.

We evaluated a bunch of solutions back in '05-'07 and finally switched everything to SVN in '07. TortoiseSVN was the key selling point. Our environment is one where the users are not overly geeky or technical and a central repository suits our needs far better. We're not an open-source shop and all code is proprietary.

They've changed their licensing to make Perforce free for small development teams and added some kind of GIT interface. My guess is so many developers are coming out of college having used GIT that it's building user lock-in.

Totally disagree with this. While I've never done any admin work with our Perforce server, we've never needed to rewrite the code. If you're working with a less featureful product, there might be a need for the code base. Perforce is enterprise-quality software.

IMHO, git is a shining example of bad design. You need too much info on how it works on the inside, to be able to use it. It is simply way too complicated. I regret the fact that it seems to be the most popular VCS for open-source projects. I'd prefer something simpler like bzr.

You will be burned at the stake for the heretical belief that Git may not be the most appropriate tool for *every* VCS need!

FWIW, I've used them all and prefer bzr (or svn, depending). Not every project is the Linux kernel, which needs to allow thousands of people to collaborate in an independent/distributed fashion... Git is great for *that*, but then again so is bzr.What?!No! Wait! It's not what it looks like, I swear!AAARGH! THE FLAMES! THEY BUUURRRNNN!

This all may be but imagine this. I work in a project where delivery time is fixed. We have a fixed time line of 6 months (now 8 due to delays). I imagine we wasted at least 3 weeks because people did not know how to deal with git and with commit,merge,pull,push i.e. basic functionalities. They knew other tools still prevalent in the rest of the company so there was no real need to switch except one engineer having a say and deciding for himself and the rest too. Now he is hardly using it and the rest never

This all may be but imagine this. I work in a project where delivery time is fixed. We have a fixed time line of 6 months (now 8 due to delays). I imagine we wasted at least 3 weeks because people did not know how to deal with git and with commit,merge,pull,push i.e. basic functionalities. They knew other tools still prevalent in the rest of the company so there was no real need to switch except one engineer having a say and deciding for himself and the rest too. Now he is hardly using it and the rest never works from home so we wasted time to learn it only because one person liked the tool. In other words - git is possibly the biggest of all version control systems but because its concepts are so different from the others it means that switching to it should be carefully considered - are benefits evaluated against the incumbent ones.

What version control system were you using beforehand?

It seems odd that you'd all decide to switch to a tool without a plan for it, especially since you can easily use Git with other VCS systems quite easily (just maintain a branch that you use when you commit back to the other tool).

Half the power of Git is that you have a fairly gentle migration path.

No wonder you are posting it as AC, I would be ashamed myself to work with such incompetent people.

I mean, WTF is so complicated with git add, git commit, git branch, git checkout, git merge, git push, git pop and git mergetool? Yes that is only 8 commands that you need to use git for production.If you are using an IDE like Eclipse, the IDE can manage git add, git commit, git branch, git checkout just fine.

That is slashdot: a troll gets +5 insightful.If you even bother to elaborate what on git is "complicated" and how that compares to bzr.

I started with Subversion and that was a pain. Then I switched to git and I didn't know anything about it but could use it in 5 minutes. After some 3 years of productive usage, and my own repositories* I still only know the high-level commands and have never any trouble.

Personally (and professionally), I use Fossil [fossil-scm.org]. It has much of the strength of Git while remaining approachable. Bonus, the built-in cgi server/bug tracking/wiki/timeline tree. All this in a single binary less than 1 Mb.

IMHO, git is a shining example of bad design. You need too much info on how it works on the inside, to be able to use it. It is simply way too complicated. I regret the fact that it seems to be the most popular VCS for open-source projects. I'd prefer something simpler like bzr.

Git is very often explained wrong. Especially for those brain-damaged by the use of CVS or SVN. (I myself was/am too). And yes, 'brain-damaged' is a quite fitting term in this case. Think switching from Basic to OOP Java. That's the

even less from alternate vendors or as ebook
Why is it so hard for the editor or submitter to include the street price on book reviews?
doesnt seem a bad price for an almost essential developers reference.
you'd think amazon marketdroids would be all over including a hyperlink to a/. special kickback price

Linus hates this concept, (covers why he hates it in some detail in his techtalk) and frankly he's right.

What you describe is the trivial case: concurrent versions when the changes don't interact at all, and their are no significant changes to the surrounding modules.

How common is this, really on any complicated project, where even minor changes might depend on the external status of any number of subsystems which might be under active development? Git makes the sensible observation that the only thing you'

Every single fucking one. And its probably the most search phrase relating to kit with the most questions and the most complete lack of fucking helpful answers. If the precious fucking git maintainers could come up with a more informative error message and a simple default action for the most common case - syncing local/remote branches then they'd probably reduce google traffic by at least 10

I reviewed the book at my own schedule, and as far as I know O'Reilly Media planned their Cyber Monday without any connection to when this review would be posted. Slashdot didn't promise me a posting schedule anyway, although a few days ago an editor wrote to say he'd probably run it on Monday. I forwarded that fact to a couple of people at O'Reilly (see below), but that was on Thursday, which was the Thanksgiving holiday in the U.S. Suffice it to say it is highly doubtful that O'Reilly Media planned their whole Cyber Monday thing starting a mere three days before the event and over a long holiday weekend!

However, I should have added a couple of disclaimers to the review:

O'Reilly sent me the copy to review, and, more importantly, the editor on the book, Andy Oram, is also my editor. The free review copy is not really worth a disclaimer, though; I'm just trying to be thorough. First of all, the amount of time it takes to read a book and write a review far outweighs the cost of purchasing a copy, and second of all, as an O'Reilly author I'm pretty sure I could have just emailed them asking for a copy anyway, regardless of whether I were reviewing it:-). As for sharing an editor: while Andy's a friend, I know he wouldn't want me to write a review differently just because he were the editor, he knows I wouldn't do so anyway, and he knows that I know that he knows I know he wouldn't want that. (The two people at O'Reilly whom I emailed about the probable Monday posting were Andy and the person who had sent me the review copy.)

So, this was not a slashvertisement -- just a coincidence, to the best of my knowledge.

A lot of people should have their geek card removed. That, or I'm totally not up-to-date. Karl Fogel of subversion fame is reviews a book on git and describes himself as an everyday user of git. Yet noone asks the obvious question: does netcraft confirm svn's death or are the reports greatly exaggerated? Or do you still see a role for subversion, e.g. as the central server which everybody uses via git-svn (the gcc people appear to be doing this)?

We moved from subversion to git and I would not look back. I liked subversion, but there is nothing in subversion that I can't also do in git, plus I can do a lot more in git. Branches and branch merging is much cleaner in git than subversion. In addition, the fact that everyone has a copy of the repository means that (a) all operations can be done offline (yay!), and (b) you have automatic backup copies of everything. I can look through all commits (using gitk) straight off of my machine whether I'm co

My experiance with git (admittedly i'm something of a git newbie so PLEASE tell me if there is an easy answer to this) is that if you don't have the commit ID for the version that was used for something it's very difficult to find it from other information. Particulally when you get developers who work on a modified version of something like linux in such a way that all the commits from upstream linux appear in their derviatives history.

Compounding this is the fact that git makes it awkward to find a commit

Normally the proper solution is to actually include in a build some way of determining the commit id used

Agreed, as usual cleaning up messes is much harder than avoiding making them in the first place.

But I still think it's a pity that in our quest to let people work locally in a versioned manner (which is a GOOD thing) we seem to have lost the ability to easilly track how "what was at the heads of branches in the main repository" changed over time.

Good God how did this get modded up. That is one of its fortes: absolute-as-absolute-gets certainty that your history is correct and complete and signed off by whatever parties you deep proper, with a mechanism so simple and straightforward anyone you'd trust to be an auditor could understand it.