Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Book Review: Version Control With Git, 2nd Edition

samzenpus posted about 2 years ago | from the read-all-about-it dept.

Books 116

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

Sorry! There are no comments related to the filter you selected.

svn commit -m 'initial commit' (4, Funny)

Qbertino (265505) | about 2 years ago | (#42097147)

First Post!

Re:svn commit -m 'initial commit' (1)

rubikscubejunkie (2664793) | about 2 years ago | (#42097187)

2nd post, same as the first.

You had me at steganographic kitten photos! (3, Funny)

mellon (7048) | about 2 years ago | (#42097531)

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.

Re:You had me at steganographic kitten photos! (2)

Old Wolf (56093) | about 2 years ago | (#42098981)

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 :)

Re:You had me at steganographic kitten photos! (1)

mellon (7048) | about 2 years ago | (#42101785)

That's just what they _want_ you to think!

Re:You had me at steganographic kitten photos! (0)

Anonymous Coward | about 2 years ago | (#42105031)

steganographic kitten photo placement service

Stuff the photos, I want the steganographic kitten itself- it's going to be the next must-have pet for geeks!

Here's one [buzzle.com] with an *extremely* rude message encoded within its stripes! See if you can tell what it says...

Re:svn commit -m 'initial commit' (0)

Anonymous Coward | about 2 years ago | (#42097557)

Repository is already up to date.

Re:svn commit -m 'initial commit' (3, Funny)

shentino (1139071) | about 2 years ago | (#42099607)

Im git the repo I am
git the repo I am I am
I got cloned from the repo next door
She's been cloned seven times before
And every one was a git
git!
Nary a cvs nor a hg
Git the repo I am I am
Git the repo I am

slashvertisement much? (-1, Offtopic)

Anonymous Coward | about 2 years ago | (#42097205)

Aaaand HOW CONVENIENT it is that O'Reilly JUST HAPPENS to have a "Cyber monday" deal that lets you have 50% off all E-book deals?

Re:slashvertisement much? (1)

rubikscubejunkie (2664793) | about 2 years ago | (#42097231)

No conspiracy herenearly everyone is having cybermonday sales.

Re:slashvertisement much? (1)

smitty_one_each (243267) | about 2 years ago | (#42097269)

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?

Re:slashvertisement much? (4, Informative)

kfogel (1041) | about 2 years ago | (#42098735)

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

Re:slashvertisement much? (0)

Anonymous Coward | about 2 years ago | (#42101687)

Not a slashvertisement, I'm just an O'Reilly author gushing about a wonderful O'Reilly book.

Understood.

Cloning is portrayed as complicated?? (2)

jthill (303417) | about 2 years ago | (#42097225)

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.

Re:Cloning is portrayed as complicated?? (1)

geminidomino (614729) | about 2 years ago | (#42097263)

OT, but since you seem to be familiar with git:

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.

Re:Cloning is portrayed as complicated?? (0)

Anonymous Coward | about 2 years ago | (#42097337)

How about giving everyone their own dev branch, then having someone merge this into the master branch?

Re:Cloning is portrayed as complicated?? (2, Informative)

Anonymous Coward | about 2 years ago | (#42097443)

Sounds like you may want gerrit [google.com] .

If you can't tell from the doc, check out this video [bandlem.com] .

Re:Cloning is portrayed as complicated?? (1)

treeves (963993) | about 2 years ago | (#42101471)

I would have called it Stupid Git.

Re:Cloning is portrayed as complicated?? (0)

Anonymous Coward | about 2 years ago | (#42097445)

Basically if you want to hold commits until they're approved then you just make it so the only one who can push to the "central" repo are those in the approver role. This could of course get messy with a fast moving code base, since the approvers would inevitably have to deal with at least some of the merges, but you could have it that any non-trivial merge is punted back to one of the developers involved and has to be reapproved afterwards.

I can't imagine it being worse than having to use subversion with the developers have to deal with having their own global dev branch (and only one?). If you're using subversion things can only really get better by using git, provided you manage to get everyone halfway competent in using it.

Re:Cloning is portrayed as complicated?? (1)

dolmen.fr (583400) | about 2 years ago | (#42099929)

Or better: anyone can push to the central repo, but only one can push to the master branch.

You can do this kind of setup with gitolite [github.com] .

Re:Cloning is portrayed as complicated?? (3, Interesting)

jthill (303417) | about 2 years ago | (#42097465)

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.

Re:Cloning is portrayed as complicated?? (0)

Anonymous Coward | about 2 years ago | (#42097487)

you should either look at Gerrit. or just continue branching and pushing remote. your workflow shouldnt have to change.

Re:Cloning is portrayed as complicated?? (2)

Dr_Barnowl (709838) | about 2 years ago | (#42097509)

What you should be doing is giving each substantial unit of change a branch.

Personal branches become fiefdoms. Unless the developer concerned is disciplined, you are in effect creating a bunch of forks.

Make a branch for each feature, bugfix, etc. It helps that the most painful thing about SVN, merging, is so much easier in Git.

Re:Cloning is portrayed as complicated?? (1)

mattack2 (1165421) | about 2 years ago | (#42100917)

Why do you call merging painful in svn?

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.

Re:Cloning is portrayed as complicated?? (1)

phantomfive (622387) | about 2 years ago | (#42101661)

It used to be extremely painful merging in SVN. They say it's changed recently.

Re:Cloning is portrayed as complicated?? (1)

mattack2 (1165421) | about 2 years ago | (#42101747)

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 URL
is 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.

Re:Cloning is portrayed as complicated?? (1)

phantomfive (622387) | about 2 years ago | (#42101881)

Well I have outright rage over CVS. Primarily because of its slowness in large projects....

It is possible the reason you don't have problems with SVN merge and I did was because you use the command line and I use tortoise. I'm not the only one who thinks it's painful, though [assembla.com] .

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. That's kind of nice, but generally I'd rather just not have two people work on the same piece of code at the same time.

Re:Cloning is portrayed as complicated?? (1)

electrofelix (1079387) | about 2 years ago | (#42104705)

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 merge and record the information somewhere else, or require that developers recorded which revisions were merged in the commit message.

The subversion developers eventually realised their mistake and added internal metadata to handle, so that if you merged r100 of branchA to branchB, and then subsequently tried to merge r200 of branchA to branchB, subversion would realise that everything prior to, and including r100 on branchA was already merged, and it need only merge the differences between r100 and r200.

Oddly enough though, by then most devs had already abandoned it for just about anything else that had sane merging.

Re:Cloning is portrayed as complicated?? (3, Informative)

Anonymous Coward | about 2 years ago | (#42097517)

http://en.wikipedia.org/wiki/Gerrit_(software)

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, too.

Re:Cloning is portrayed as complicated?? (1)

DarkTempes (822722) | about 2 years ago | (#42097535)

https://help.github.com/articles/using-pull-requests [github.com] works well when you let everyone have their own "fork" but afaik wouldn't work for a single shared repository.

You can also do it the same way you do with subversion though in which everyone has commit/push access to the same repo and just create a lot of branches.

And obviously you can mix the two methods just fine.

Re:Cloning is portrayed as complicated?? (0)

Anonymous Coward | about 2 years ago | (#42100877)

The Github model works great in Enterprise situations that typically have a single, shared repository. The key is that you actually need the Github software. Git is an unfinished product and Github finishes it. The answer to GP's question is to either host code at Github or install their Enterprise [github.com] software.

Re:Cloning is portrayed as complicated?? (3, Insightful)

hackula (2596247) | about 2 years ago | (#42098829)

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.

Re:Cloning is portrayed as complicated?? (1)

fatphil (181876) | about 2 years ago | (#42100901)

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 tree, for which they send a pull request (git request-pull) (after of course they've sent the patchset for review, and got some s-o-b's, ack's, or r-b's, and preferably some tested-by's too). Pull it onto a branch on your tree. If it doesn't apply, then ask them to rebase. If it passes sanity tests, then merge (which should be a fast-forward).

I maintained the linux kernel at work this way quite happily for quite a while. Had pull requests from many dozens of develpers, and the process was mostly trivial (as it was mostly scripted). The hardest part was tracking the upstream kernel, as of course failures to merge couldn't be met with "please rebase" - I had to do all the fixups myself. Fortunately, we were based on an old stable, so were relatively slow-moving.

Re:Cloning is portrayed as complicated?? (0)

Anonymous Coward | about 2 years ago | (#42097861)

Linus hatred of C++ stems from its use in a kernel, where simplicity is important. It makes sense for git.

Re:Cloning is portrayed as complicated?? (1)

serviscope_minor (664417) | about 2 years ago | (#42099249)

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.

Re:Cloning is portrayed as complicated?? (1)

jthill (303417) | about 2 years ago | (#42100105)

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 you :-)

Two thumbs up, and maybe a tentacle too... (1, Informative)

xxxJonBoyxxx (565205) | about 2 years ago | (#42097285)

Did a certain editor watch a little hentai this weekend?

Re:Two thumbs up, and maybe a tentacle too... (0)

Anonymous Coward | about 2 years ago | (#42097363)

ive seen enough commits to know where this is going

Re:Two thumbs up, and maybe a tentacle too... (4, Informative)

Anonymous Coward | about 2 years ago | (#42097463)

I'm guessing you're going for the +1 Funny mod, but just in case, let it be known by each and everyone that GitHub's mascot is an octocat [github.com] .

Read Pro Git first (3, Interesting)

flimm (1626043) | about 2 years ago | (#42097309)

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.

git flow? (3, Interesting)

vlm (69642) | about 2 years ago | (#42097353)

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?

PFT! Version control is for sissies. (5, Funny)

Deus.1.01 (946808) | about 2 years ago | (#42097367)

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

Re:PFT! Version control is for sissies. (1)

vlm (69642) | about 2 years ago | (#42097423)

That file naming convention is too predictable. Around here we use names like:
winter-project
nov-15-project
project-2.0
11.05.12-project
project-somebodys-name

Which one is the most recent? Oh look at the last modified date for the file, of course.

Re:PFT! Version control is for sissies. (1)

rubikscubejunkie (2664793) | about 2 years ago | (#42097903)

I grew up in the projects..I know. :)

Re:PFT! Version control is for sissies. (1)

Synerg1y (2169962) | about 2 years ago | (#42099671)

It's funnier when you walk into an environment with something like tfs in place and you see that kind of naming convention in use anyways...

Speaking from exp.

And then somebody makes an argument that all devs should be paid equal and the servers start smoking :)

Re:PFT! Version control is for sissies. (0)

Anonymous Coward | about 2 years ago | (#42098287)

Version control? Isn't that why they made USB Sticks?

Re:PFT! Version control is for sissies. (0)

Anonymous Coward | about 2 years ago | (#42098799)

Reading a 456 page book on version control seems a waste of time. (Unless lots of your life resolves around merging code).

Re:PFT! Version control is for sissies. (1)

rubikscubejunkie (2664793) | about 2 years ago | (#42099107)

Not so. If shops had better version control, coding would be quicker, let bugs, cheaper software...so a 456 page book...just ok w/ me.

Re:PFT! Version control is for sissies. (1)

Synerg1y (2169962) | about 2 years ago | (#42099705)

:( 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 introduction on how to not delete your code with tfs.

Re:PFT! Version control is for sissies. (1)

rubikscubejunkie (2664793) | about 2 years ago | (#42105405)

I stand corrected :)

Re:PFT! Version control is for sissies. (0)

Anonymous Coward | about 2 years ago | (#42099165)

With regular version control you're correct. Git however is a mess of leaky abstractions and misfeatures and requires an expert to do things that would be mundane less silly systems.

Re:PFT! Version control is for sissies. (0)

Anonymous Coward | about 2 years ago | (#42100137)

My experience with "less silly systems" suggests that the mundane things list is 2 items, and everything else is either impossible to do or doesn't quite do what you want. That and those 2 items aren't any harder to do in git, people just get confused by the staging area.

Re:PFT! Version control is for sissies. (1)

Anonymous Coward | about 2 years ago | (#42102423)

"X's aren't any harder to do in git, people just get confused by Y"

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"

Re:PFT! Version control is for sissies. (0)

Anonymous Coward | about 2 years ago | (#42103469)

There are different kinds of hard.
1)How long does it take for an expert to do it?
2)How long does it take for a beginner to do it?
3)How long does it take for an expert in a different tool, who is a beginner in this one?

There are a large number of things that are trivial for an intermediate/expert git user to do using git that are damn near impossible to do in SVN.

Basically GIT does well with 1 and so-so with 2, but terrible with 3
SVN does poorly with 1, good with 2, and 3... the only sane person who's an expert with another tool switching to SVN is just in the process of leaving CVS...

Git fucken sucks the fucken wang (-1)

Anonymous Coward | about 2 years ago | (#42097667)

Fucken fagets and their motherfucken Git bullshit. There all fagets, sending each other pull requests cuz they wanna pull on each other's fucken dongs.

Fucken Git fagets.

Fantastic Review (1)

ustolemyname (1301665) | about 2 years ago | (#42097905)

That is possibly the best review of a technical book I have ever read. Thank you!

450 pages?! (1)

Maury Markowitz (452832) | about 2 years ago | (#42097927)

Coles Notes version please.

Ironic (1)

Arancaytar (966377) | about 2 years ago | (#42098013)

If you try to skip around, or just read the parts you feel you need

That's ironic, because those are the features that make git so awesome.

Slightly OT: Perforce trying to counter GIT surge (3, Interesting)

GodfatherofSoul (174979) | about 2 years ago | (#42098047)

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.

Re:Slightly OT: Perforce trying to counter GIT sur (2)

kfogel (1041) | about 2 years ago | (#42098785)

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.

Re:Slightly OT: Perforce trying to counter GIT sur (0)

Anonymous Coward | about 2 years ago | (#42099119)

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.

Re:Slightly OT: Perforce trying to counter GIT sur (0)

Anonymous Coward | about 2 years ago | (#42102447)

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.

Re:Slightly OT: Perforce trying to counter GIT sur (2)

GodfatherofSoul (174979) | about 2 years ago | (#42099207)

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.

Re:Slightly OT: Perforce trying to counter GIT sur (2)

shentino (1139071) | about 2 years ago | (#42099635)

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.

Git not version control/sourrce control. (-1)

MouseTheLuckyDog (2752443) | about 2 years ago | (#42098345)

Really it's more of a patch managment system then anything else.

It's not really ( compared to established version control systems ) convenient for managers,lawyers due, QA or serious developers due to lack of a clear history/ audit trail. Fact is it is only convenient to the high level developers who merge patches into the main tree, ie, it is only useful to the people who are in the same position as Linus.

Re:Git not version control/sourrce control. (2)

johnnyb (4816) | about 2 years ago | (#42098959)

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.

Re:Git not version control/sourrce control. (1)

Anonymous Coward | about 2 years ago | (#42099209)

It's not really ( compared to established version control systems ) convenient for managers,lawyers due, QA or serious developers due to lack of a clear history/ audit trail.

You haven't actually used git, have you?

Re:Git not version control/sourrce control. (1)

Synerg1y (2169962) | about 2 years ago | (#42099739)

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.

Re:Git not version control/sourrce control. (1)

petermgreen (876956) | about 2 years ago | (#42101107)

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?

Re:Git not version control/sourrce control. (0)

Anonymous Coward | about 2 years ago | (#42103521)

git reflog

Re:Git not version control/sourrce control. (0)

Anonymous Coward | about 2 years ago | (#42099759)

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 [git-scm.com] )? Used the blame command in git? No, of course not.

Re:Git not version control/sourrce control. (1)

jthill (303417) | about 2 years ago | (#42100269)

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.

Re:Git not version control/sourrce control. (0)

Anonymous Coward | about 2 years ago | (#42101293)

"...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.

Re:Git not version control/sourrce control. (2)

phantomfive (622387) | about 2 years ago | (#42101683)

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.

Git is way too complicated (4, Insightful)

HyperQuantum (1032422) | about 2 years ago | (#42098429)

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.

Unbeliever! (3, Insightful)

Anonymous Coward | about 2 years ago | (#42098737)

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!

Re:Git is way too complicated (2)

Old Wolf (56093) | about 2 years ago | (#42098937)

I have no idea how git works on the inside, and make great use of it. It is such a massive time-saver coming from CVS.

Re:Git is way too complicated (2, Insightful)

Anonymous Coward | about 2 years ago | (#42099371)

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.

Re:Git is way too complicated (3, Insightful)

lattyware (934246) | about 2 years ago | (#42100375)

Seriously, if it takes anyone on your team 3 weeks to learn how to use GIT at a basic level, you need to find new people.

Re:Git is way too complicated (1)

Electricity Likes Me (1098643) | about 2 years ago | (#42103267)

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.

Re:Git is way too complicated (1)

devent (1627873) | about 2 years ago | (#42104481)

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.

Re:Git is way too complicated (0)

Anonymous Coward | about 2 years ago | (#42100813)

Could you make a list of revision control systems that aren't huge time-savers coming from CVS? I can list two, SCCS and RCS, both predate CVS and it isn't a surprise they're more primitive. Almost anything is a huge improvement over CVS, since most things came after CVS.

Re:Git is way too complicated (1, Insightful)

Anonymous Coward | about 2 years ago | (#42099665)

+1 for you. Git's internals may be nice, but its usability (or lack thereof) is epic fail

Re:Git is way too complicated (0)

Anonymous Coward | about 2 years ago | (#42099679)

I'd prefer something simpler like bzr.

The same bzr that has a million semi-overlapping concepts and no clear explanation of what the differences are or why they all exist in the first place? You consider that simpler than a collection of well-defined operations over a straightforward documented core data model? What are you smoking, and can I have some?

Re:Git is way too complicated (1)

devent (1627873) | about 2 years ago | (#42104173)

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.

* https://www.anr-institute.com/gitpublic/ [anr-institute.com]

Re:Git is way too complicated (0)

Anonymous Coward | about 2 years ago | (#42104243)

I use git for a small php project and android app I am working on at work. I have 0 years experience with svn, and am not a programmer by trade. Have you considered that maybe git is not the problem?

Re:Git is way too complicated (2)

JigJag (2046772) | about 2 years ago | (#42105093)

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.

Re:Git is way too complicated (0)

Anonymous Coward | about 2 years ago | (#42105183)

Translation: I don't understand git not do I want to learn it. I wish the most popular VCS for open-source projects had been my personal favourite.

What is this I don't even (3, Insightful)

Old Wolf (56093) | about 2 years ago | (#42098917)

The reviewer has clearly read the book he is writing a review for.. what is the world coming to

eh, what? (1)

Anonymous Coward | about 2 years ago | (#42099061)

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.

Get it on Safari today! (2)

beat.bolli (126492) | about 2 years ago | (#42099315)

Discount code CYBERDAY gets you 50% off at O'Reilly's shop [oreilly.com] until November 26, 2012 at 11:59pm PT!

$23.03 on Amazon ATM (1)

Anomalyst (742352) | about 2 years ago | (#42099699)

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

Teamware was nicer (0)

Anonymous Coward | about 2 years ago | (#42100319)

Decades back I had the privilege of working with a version control tool called Teamware [wikipedia.org] . 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.

Re:Teamware was nicer (1)

Electricity Likes Me (1098643) | about 2 years ago | (#42103291)

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're really sure of is that the version you are working on, right now, you understand, and is designed to work together - and that plucking out any one file and changing it, could break things in any number of ways.

On every single git project I've worked on (1, Flamebait)

blackpaw (240313) | about 2 years ago | (#42101647)

# 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%

Re:On every single git project I've worked on (1)

rippeltippel (1452937) | about 2 years ago | (#42103175)

A 'git push' every now and then may help* in these cases... ;-)

* (both you and the other guys working on your project)

Re:On every single git project I've worked on (3, Informative)

blackpaw (240313) | about 2 years ago | (#42104389)

Version control ... sigh ... (1)

mikein08 (1722754) | about 2 years ago | (#42101831)

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.

Predictable (0)

Anonymous Coward | about 2 years ago | (#42104077)

What's so very good about this book? It's from O'Reilly? Try being less predictable.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?