Book Review: Version Control With Git, 2nd Edition 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.
| 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. |
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.
svn commit -m 'initial commit' (Score:5, Funny)
First Post!
Re: (Score:1)
You had me at steganographic kitten photos! (Score:4, Funny)
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: (Score:3)
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: (Score:2)
That's just what they _want_ you to think!
Re:svn commit -m 'initial commit' (Score:4, Funny)
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
Cloning is portrayed as complicated?? (Score:3)
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: (Score:2)
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: (Score:1)
Re: (Score:2, Informative)
Sounds like you may want gerrit [google.com].
If you can't tell from the doc, check out this video [bandlem.com].
Re: (Score:2)
I would have called it Stupid Git.
Re: (Score:2)
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?? (Score:4, Interesting)
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: (Score:3)
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: (Score:2)
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: (Score:2)
Re: (Score:2)
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: (Score:2)
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. Th
Re: (Score:1)
The consequence of this was that many teams ended up having to create custom tools to perform the mer
Re: (Score:3, Informative)
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, t
Re: (Score:2)
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?? (Score:4, Insightful)
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: (Score:2)
Each coherent change (one feature, one bugfix, one update) should be on a branch in their
Re: (Score:2)
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: (Score:2)
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
Two thumbs up, and maybe a tentacle too... (Score:2, Informative)
Did a certain editor watch a little hentai this weekend?
Re:Two thumbs up, and maybe a tentacle too... (Score:4, Informative)
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 (Score:3, Interesting)
git flow? (Score:4, Interesting)
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. (Score:5, Funny)
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: (Score:2)
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: (Score:1)
Re: (Score:2)
Speaking from exp.
And then somebody makes an argument that all devs should be paid equal and the servers start smoking
Re: (Score:1)
True, and so is the version control idea I stole:
age file
does "mv file file-; cp -p file- file" so you end up with files named "file" and "file-". age again and you get file, file- file--.
Which one is the most recent? In this example, it's always the file named "file".
Simple but very effective. However, I'm moving into the 21st century with git.
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
Re: (Score:1)
"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: (Score:2)
the only sane person who's an expert with another tool switching to SVN is just in the process of leaving CVS...
Or RCS. Or SCCS. Or PVCS. Or Clearcase. Or (shudder) Visual SourceSafe. There are a lot of tools out there that are more painful than Subversion...
Re: (Score:2)
We evaluated a bunch of solutions back in '05-'07 and finally switched everything to SVN in '07. TortoiseSVN was the key selling point. Our environment is one where the users are not overly geeky or technical and a central repository suits our needs far better. We're not an open-source shop and all code is proprietary.
I've looked at git a few times, it just doesn't meet our needs.
Fantastic Review (Score:2)
450 pages?! (Score:2)
Coles Notes version please.
Ironic (Score:2)
That's ironic, because those are the features that make git so awesome.
Slightly OT: Perforce trying to counter GIT surge (Score:4, Interesting)
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: (Score:3)
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: (Score:3)
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: (Score:3)
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 is way too complicated (Score:5, Insightful)
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! (Score:3, Insightful)
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: (Score:3)
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: (Score:2, Insightful)
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
Re:Git is way too complicated (Score:4, Insightful)
Re: (Score:2)
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: (Score:2)
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: (Score:1, Insightful)
+1 for you. Git's internals may be nice, but its usability (or lack thereof) is epic fail
Re: (Score:2)
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: (Score:3)
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.
I dispute that statement (Score:2)
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 [kernel.org]
It's often explained wrong. (Score:2)
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
What is this I don't even (Score:4, Insightful)
The reviewer has clearly read the book he is writing a review for.. what is the world coming to
eh, what? (Score:1)
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! (Score:2)
$23.03 on Amazon ATM (Score:2)
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
Re: (Score:2)
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'
On every single git project I've worked on (Score:2, Flamebait)
# 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: (Score:1)
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 (Score:4, Informative)
You've obviously never run into the problem, its never that simple.
Google [google.com.au]
A *small* sample of the results. All of which have various different answers, all a variation on each other, none of which consistently work. Bonus - many cryptic meanigless error messafes.
http://stackoverflow.com/questions/9050978/your-branch-is-ahead-of-origin-master-by-1-commit-on-explicit-push [stackoverflow.com]
http://stackoverflow.com/questions/277077/why-is-git-telling-me-your-branch-is-ahead-of-origin-master-by-11-commits-a [stackoverflow.com]
http://stackoverflow.com/questions/2432579/git-your-branch-is-ahead-by-x-commits [stackoverflow.com]
http://stackoverflow.com/questions/2342618/git-your-branch-is-ahead-of-origin-master-by-3-commits [stackoverflow.com]
http://stackoverflow.com/questions/10820118/your-branch-is-ahead-of-origin-master-by-1-commit-after-merge [stackoverflow.com]
http://www.freewayprojects.com/2011/11/solving-the-your-branch-is-ahead-of-originmaster-by-x-commits-issue-after-pulling-using-git/ [freewayprojects.com]
Version control ... sigh ... (Score:1)
Minor typo in review. (Score:2)
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 [slashdot.org] .
-Karl Fogel
Re: (Score:2)
They fixed it fast! (I'd delete the original comment now if I could.)
Re: (Score:1)
Re: (Score:1)
If so, do you feel honored by this shower of golden affection?
Re:slashvertisement much? (Score:5, Informative)
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
svn dead? (Score:4, Insightful)
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)?
Re: (Score:2)
I use SVN daily too. Sometimes SVN is the right tool for the job, sometimes Git is.
-Karl
Re: (Score:2)
The disclaimers are important. Still, it was an excellent review: critical, fair-handed, and detailed.
Re: (Score:3)
We moved from subversion to git and I would not look back. I liked subversion, but there is nothing in subversion that I can't also do in git, plus I can do a lot more in git. Branches and branch merging is much cleaner in git than subversion. In addition, the fact that everyone has a copy of the repository means that (a) all operations can be done offline (yay!), and (b) you have automatic backup copies of everything. I can look through all commits (using gitk) straight off of my machine whether I'm co
Re: (Score:1)
You haven't actually used git, have you?
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
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?
Re: (Score:2)
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.
Re: (Score:2)
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: (Score:3)
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.