Slashdot Mirror
Book Review: Version Control With Git, 2nd Edition
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.
You can purchase Version Control with Git: Powerful tools and techniques for collaborative software development from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
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.
You can purchase Version Control with Git: Powerful tools and techniques for collaborative software development from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
First Post!
We suffer more in our imagination than in reality. - Seneca
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.
As always, all IMO. Insert "I think" everywhere grammatically possible.
No conspiracy herenearly everyone is having cybermonday sales.
Are you saying that capitalism is treating you as a greater idiot than socialism?
If so, do you feel honored by this shower of golden affection?
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
Did a certain editor watch a little hentai this weekend?
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?
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
I have my own simple and versatile way of keeping track of branches.
*Project
*Copy of project
*Copy of Copy of project
*Copy of Copy of copy of project
My -1 Troll is actually a +1 funny. And my -1 flame is actually a +1 insightfull.
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.
That is possibly the best review of a technical book I have ever read. Thank you!
Coles Notes version please.
That's ironic, because those are the features that make git so awesome.
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.
I swear to God...I swear to God! That is NOT how you treat your human!
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.
I am not really here right now.
Nope, no coordination nor conspiracy.
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.
Best,
-Karl Fogel
http://www.red-bean.com/kfogel
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!
It is not possible to compete with Git on its own terms without being open source. Being zero-charge for small teams is not going to cut it, IMHO.
http://www.red-bean.com/kfogel
The reviewer has clearly read the book he is writing a review for.. what is the world coming to
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 connected or disconnected. It's wonderful.
Engineering and the Ultimate
I find it hard to reconcile the high rating given to the book with the actual review. It seems like a very long list of very fundamental flaws with the book concluded with "so it's great!".
Of course, people who like git are perhaps the kind of people who like reading an overly complex and confused book as some kind of puzzle.
Not true. Very few teams need or want "open source" version control - that's a tangential benefit at best, not a primary feature. Open Source is warm and fuzzy sounding, but I've never, in nearly 20 years of development team support (most of it in DevOps/Tools/Release Engineering roles) had a single team say "... and it's GOTTA be open source," though I have had numerous teams say "and keeping licensing and support costs down is of critical importance." On that score, perforce can *certainly* compete with git without being open source as well.
You CAN run git in-house for free, but most companies larger than N (where "N" is roughly 20 developers) will start saying, "We should have vendor support for this." At that point, it doesn't matter much WHO you pay for support - github, or perforce, you're still going to spend support dollars.
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.
I swear to God...I swear to God! That is NOT how you treat your human!
You haven't actually used git, have you?
Discount code CYBERDAY gets you 50% off at O'Reilly's shop until November 26, 2012 at 11:59pm PT!
Karma: none (due to not believing in reincarnation)
It's fine for me.
Git's source code is open and there's no DRM on top of the data storage format.
So any lock-in is completely voluntary on behalf of the user.
even less from alternate vendors or as ebook /. special kickback price
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
There is no right to feel safe thru security vaudeville at the expense of everyone's freedom, privacy and tax money.
Yep, GIT has stuff like blame, committed by, & change control, bu then again so does just about any modern versioning system. OP probably doesn't write code based on comment and lack of detail.
It's not really[...]convenient[...]due to lack of a clear history/ audit trail.
WHAAAAAT? Are you serious? clear history? Have you ever seen git history (hint, it looks like this)? Used the blame command in git? No, of course not.
clear history/ audit trail
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.
As always, all IMO. Insert "I think" everywhere grammatically possible.
Decades back I had the privilege of working with a version control tool called Teamware. I suppose its important features were inherited by its descendant Bitkeeper, which I haven't tried. I have worked with Perforce, CVS, SVN. I have evaluated Mercurial and looked at git. None of these other tools rise to the level of Teamware.
The mistake Mercurial (and git, apparently) are making is that they treat the whole workspace as the versioned "file". That means two developers making independent changes to different files are generating a conflict, which needs to be resolved artificially. Thus, the workspace will record the independent changes A and B as either AB or BA. One important victim of this unfortunate principle is that cherry-picking becomes cumbersome and unnatural. Another one is developers' exchanging "prereleases" of their enhancements numerous times before committing them to the release branch.
Teamware kept the version focus on files. Each file had a separate version history. Individual changes could be transported between "branches" without conflicts and without contaminating the version histories with irrelevant branching/merging information (as you have to do in CVS).
Darcs' patch algebra seems to combine the two approaches, but I understand it can become computationally unwieldy. In my experience Teamware's naive file focus hit the sweet spot.
Teamware could be emulated by Mercurial or git by keeping every single versioned file in a separate workspace. That is hardly an ideal usage pattern though. Much nicer would be "dumbing" the tools down to the level of the legendary Teamware.
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's children.
Am I missing something? Is there something to trace what commits were at some point at the head of a particular branch in a particular repo rather than merely being imported as parents of the head that the developer pushed/pulled?
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
"...due to lack of a clear history/ audit trail..."
This is uncited bullshit and you should be ashamed, maybe you were using gedit and got confused.
# On branch master
# Your branch is ahead of 'origin/master' by commits.
#
nothing to commit (working directory clean)
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 can't believe this comment is still modded up. It should be modded troll, I assume you are not that ignorant.
Not only does it have a clear history/audit trail, the trail is backed up all over the place so it is extremely difficult to forge that trail.
"First they came for the slanderers and i said nothing."
Not a slashvertisement, I'm just an O'Reilly author gushing about a wonderful O'Reilly book.
Understood.
Version control was a solved problem 20+ years ago ... if you used VMS, that is ... Unfortunately VMS was never cool, for some reason I can't fathom.
Git has literally ZERO need for vendor support. Ergo, if folks would object to git on those grounds, then either you have hired the wrong folks, or you are working for the wrong folks.
git reflog
What's so very good about this book? It's from O'Reilly? Try being less predictable.
I was using git long before I knew any nitty gritty details. Here's a useful site for beginners: Everyday GIT With 20 Commands Or So
Linux also has literally ZERO "need" for vendor support. And yet, Red Hat's a multi-billion dollar concern by providing just that thing that's absolutely not necessary.
Why? Because corporations tend to like support contracts, rather than relying on single internal points of failure to keep everything running. If you're not planning for the inevitable "hit by a bus" scenario and building that into your corporate operations, then you are the wrong guy to hire, and you are not doing the job you were hired to do.
"Open source" is not some magical "get out of expending effort and time" solution; either you do it internally by hiring an engineer who is partly (or fully) assigned to managing the system, or you sign support agreements with external providers (or some blend of the two). Either way, neither tool is "free," and it's quite easy to imagine scenarios where perforce would have a lower cost to operate and maintain than git - especially given the recent sad proliferation of "git experts" I've seen on the market who think that knowing how to clone a repo off github qualifies them as expert admins.
Just read the docs and it seems that lets you see the history of a branch within your local repository. Is there any way to do the same for a remote repository?
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Odd typo (or transcript-o) -- the word "privatizations" should be "prioritizations" in this sentence:
"Given the huge topic space the authors had to choose from, their privatizations [should be 'priorizations'] are intelligently made and obviously reflective of long experience using Git."
I don't know how that happened. It was "prioritizations" in my submission at http://slashdot.org/submission/2368485/book-review-version-control-with-git-2nd-edition .
-Karl Fogel
http://www.red-bean.com/kfogel
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)?
I don't really know, its never come up for me. To be honest just saying 'git reflog' was a bit silly of me, I'm pretty sure its actual purpose is making it easier to restore your repository to a good state if you happen to do something fairly destructive, rather than for tracking down commits made to a build.
However your actual problem isn't actually much different from what you have in most VCS, you know when a given commit was made, but not when the machine a build was made on updated to that revision/commit. Normally the proper solution is to actually include in a build some way of determining the commit id used (this is true of both svn and git), from there it is trivial to determine what patches are included in it that weren't included in another build (for example in git going "git good_commit..bad_commit" will tell you all the commits present in bad_commit that weren't also in good_commit).
err sorry, i meant "git log good_commit..bad_commit"
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 magnitude we're talking about here.
A matter of fact is that Git is extremely easy to understand, as every concept it covers is exactly everything you need to know about versioning in order to understand versioning correctly. The main problem I think is that with distributed Git, everything one knows about Subversion as a commit actually is covered by 'git push' which, as it involves merging two single repositories, allways includes a merge. Imperative merges are rarely done in regular use of centralized subversion, which is why Git may seem cumbersome initially. However, it never gets more complicated that understanding that concept of 'git push', your regular special-case superset of a merge. In fact, this is one of the great advantages of the Git workflow. Since basically everything team related always has a merge involved, merges begin to lose their scare and become a part of every-day regular versioning usage. Which is exactly how it should be.
Once one has gotten over the initial speed bump in learning, especially the one involved in moving from Subversion to Git, the insights are bedazzling. If you've used Git correctly in a Subversion replacement scenario, going back to SVN appears like going from Linux to DOS and you finally understand what Linus Torwalds was ragging about in that famous Google TechTalk on Git. And that's just for the regular versioning stuff you know from SVN, and not even including things like 'git rebase' or other luxuries.
I find a great introduction into the right way of grasping Git for the 'impaired by SVN usage' is this commercial video lecture by the PragProg people (10min Preview for free).
Their book on Git seems to be in the same ballpark quality wise.
After moving from SVN to Git - which took a few weeks time to get the hang of - I have to say that I now would second almost everything Linus Torwalds has to rag on about Subversion. Whenever I'm at my job where we use SVN, it feels like I've stepped back a decade or two. The crappyness of subversion and the elegance of git are simply unfathomable if you haven't used both extensively in versioning your projects. I personally find that even if you use Git as a drop in replacement for Subversion, mimicking the workflows including a centralised repos only used for pushing towards and pulling from, it still is light-years ahead of Subversion in every (un)imaginable way. Even the small things like configuring your ignores compare like Linux and DOS commandline between Git and Subversion respectively.
My KO criteria for Git 2-3 years ago used to be the lack of usable GUIs for Git and the abundance of mature SVN GUIs. However, today I'd stick with Git, even if all GitGUIs would vanish overnight.
My conclusion: ... The downside of that will be, of course, that you will lose your blissfull ignorance of the crappyness of subversion and will suffer whenever required to use it, be it at your job or elsewhere. :-)
I strongly suggest you bite the bullet and wrap your head around what that what appears first as some arcane concept of Git and get to use it regularly. You'll very quickly find that Git has it right and Subversion has it wrong in countless ways you weren't even aware of. That's my experience anyway.
My 2 cents.
We suffer more in our imagination than in reality. - Seneca
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.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
The disclaimers are important. Still, it was an excellent review: critical, fair-handed, and detailed.
I see what you're saying, but the fact that we ever had that information was at best a side effect. With subversion every commit had to be to the head of the main repository, but you still didn't know for certain what commit a given checkout was building from, the best you could do was infer it from timestamps if the checkout in question was automatically updating regularly.
And really the HEAD of branches in the "main" repository is irrelevant for this purpose. What you want to track is the heads of branches in the respository the builds are being made from, which if you're desperate you *can* use "git reflog" for, of course how easy this is to achieve depends on your sysadmin.