Why we chose Git, a rebuttal
unethicalblogger.com
unethicalblogger.com
Programmers like branching because it lets them be less conservative in their planning. Project managers hate branching for exactly the same reason; only one branch is going to be the actual product and the other branches are wasted effort.
Not necessarily. Where I work, the primary software development happens on embedded telecom hardware, which is then supported for years and years later. We have many different current and legacy versions of the same codebase that are still in various stages of development, production, sales, and supprot. On top of that, there are multiple releases of each version for various types of customers.
Now granted, we don't use Git (or any sort of modern VCS/DVCS), but the need for branching is very real and does not always stem from whimsical developers. There are plenty of real-world scenarios where intelligent branching is a huge benefit.
Another situation I know of is the Mantis Bug Tracker project that I work on. We just recently switched from Subversion to Git, and we have three primary branches in our repository for the old-stable, current-stable, and development versions of MantisBT. We use Git's branching to allow us to work on large changes to the legacy codebase without disrupting the stability of the development branch, and Git allows changes from one branch to be very easily ported to parallel or older branches.
"Herding cats" seems like an indirect substitution for "I don't like branches so no-one should use them."
Git moves the 'good enough?' check from commit time- which a) is harder to perform (since the codebase is changing under you) and b) forces a context switch - to merge/pull-from-developers time (which is much, much easier to manage with git.)
DVCS is basically a partial technological solution to a problem (change control) formerly solved by process- interaction between the change control authority and developers. With DVCS the change control authority can avoid having to interrupt development workflow as much, which is a good thing.
I like git, and use it, but I'll be honest and say the only thing "killer" about it for me is github.
Have you tried it? It just works more often than an svn merge.
There are a variety of reasons for that. Git records more data about where the branch originated from, when it's been merged previously, etc. That makes it easier to merge successfully, without conflicts.
Sometimes things just conflict, though, and Git can't do anything about that. Git makes it very easy to get to an un-conflicted state quickly, though, even if it means forgetting the merge all together. svn is slightly less leniant, and if you say "merge", your only options are to fix the conflicts, commit the conflicted files (and be murdered by your coworkers), or throw away your working copy. Not fun.
So to answer your question -- merges no longer cause pain. They either Just Work, or you can revert them easily.
I use it every day, and don't find this to be true. I have to resolve conflicts at about the same rate as I did with Subversion.
"Git makes it very easy to get to an un-conflicted state quickly, though, even if it means forgetting the merge all together. svn is slightly less leniant, and if you say "merge", your only options are to fix the conflicts, commit the conflicted files (and be murdered by your coworkers), or throw away your working copy. Not fun."
Don't be silly. When it comes to conflicts, you can either resolve them, or throw the merge away. Git is no different than Subversion in this regard.
Git doesn't even allow merges into a dirty branch (for the same reason), so I'm not sure what point you're trying to make.
svn does not let you check in changes if your working copy is "out of date". You have to svn update before svn commit, which is the whole problem. (Remember "svn update" is a merge, and can cause conflicts.)
If you're just complaining that sometimes you have to resolve conflicts on update, and that if you don't want to lose your local work by throwing away an update (aka "a merge"), then I have three responses for you:
1) You've got to update trunk someday anyway; suck it up and resolve the conflict.
2) If you're truly terrified of this, work on a branch (aka the Git solution -- which is totally supported in SVN!)
3) If even that doesn't work for you, just copy the files to a backup before you update.
I think you're just inventing problems for the sake of finding problems with a system that you don't like. Subversion is very simple; these situations aren't that hard to figure out.
Basically, svn has no features I want, and it doesn't work as well as git... so there is no reason for me to use it.
If you like svn, that's fine... but you have to realize that it's losing mindshare because most people don't like it as much as git -- often for reasons like the one I mention above.
I think you're just inventing problems for the sake of finding problems with a system that you don't like.
No, this is a real problem that has caused me much annoyance. Obviously I didn't die, but who wants to waste time dealing with inadequate tools?
Subversion is very simple; these situations aren't that hard to figure out.
No, it's not. Read the source code before you write a rebuttal, though -- it's enlightening.
The other huge factor I find that helps with maintaining git release/signed-off/otherwise cherrypicked branches is that git commits tend to be smaller and more discrete (due to, among other things, git stash and cheap history operations) -- I almost never see commits like 'Updates' and then 10-20 files with git, and they're endemic with every SVN/p4 instance I've seen.
It's pretty easy to stash your changes and make a tiny fix with git. Separating things out into discrete changes with SVN (and p4, named changelists don't help that much) usually involves some vimdiff/ediff and patch pain. There are some utils to make it easier, but git makes it trivial.
Apparently a lot of Git users haven't heard, but you can branch in Subversion, too. That's why "svn merge" exists -- it's a core feature! Yes, you have to remember the branch point and change directories to do it (and I grant that this is slightly annoying), but in my experience, the results are equivalent. You still have to resolve conflicts at about the same rate as with any other revision-control system. And the annoyance that Git saves you (by remembering the branch point and saving a 'cd'), is more than offset by the extra complexity of multiple masters, obtuse commands, non-local branches, and the oddball, multi-stage commit process.
To me, the extra complexity of Git is only justified when you're working on a project that has multiple, far-flung contributors who frequently work offline. Otherwise, to extend the author's metaphor, using Git is a lot like having a good set of work pants -- but wet, with sand in the crotch.
I branch at least several times a day when working on a project in git, and often throw them away quite soon afterward.
Why does every defense of Git seem to begin with a personal attack on the intelligence and knowledge of the critic? Trust me -- I understand the value of branches. I branch frequently in Subversion, and have never had problems (however "heavy" the branches may have been).
The primary feature of Git is distributed development, not branching.
Branches (in the sense of SVN, p4, etc) are a subset of the functionality that distributed development entails (local history, cheap copy operations, fast merge, etc). You can get a ton of mileage out of git, hg, etc without any distributed collaborators.
The point remains, branching in SVN is much more expensive. There's no comparison.
Touché.
Because nearly every argument I've heard against Git has been stupid or just plain wrong. It isn't necessarily true that a person making a stupid argument is stupid, but it seems to be true more often than not.
I am usually aim for something a bit more civil than "you're stupid", but I've certainly thought that very loudly when reading criticisms of Git. I gave a Git talk at a local user group meeting recently. One audience member was deeply upset about "git reset" and how Git should never be used because of that feature. I thought to myself, "I guess you never use the backspace key either." (And of course said, you can easily delete commits with Subversion. svnadmin dump, edit the dump in your text editor, svnadmin load. I have done this to correct bad merges in the past -- deleting commits is much easier than living with a dumb mistake for the rest of my life.)
Anyway, I think my point is that a lot of people are afraid of anything new, and they come up with dumb arguments to convince themselves that the new thing is bad. Git is very new, and version control is a touchy subject, so a lot of bad (and ignorant) arguments come up. It is really sad, actually. When I discover a new way of thinking that makes my life easier, I don't get upset. My life has become more enjoyable... why would I not want that!?
When you find yourself thinking this, it's a good sign that you need to take a step back, take a deep breath, and think a little harder about your opponent's arguments.
If you're getting as many merge conflicts with Git and as you were in Subversion then something is seriously broken with your team's development strategy. Git is built with a much better merge algorithm, such that conflicts should happen less often. Git was built to merge hundreds of lines of kernel code every day, and if it didn't do that quickly and accurately, there would have been no point to the project.
The extra complexity you speak of is negated by the fact that you don't have to use the "confusing" features if you don't want to! This is the number one thing that upsets me when people give Git a hard time.
99% of the time I come across someone that says Git sucks is because they ran a command like 'git-filter-branch' when they were trying to do something clever and it wiped out their data.
I don't Git should have to apologize for giving more power to developers as long as they're comfortable using it.
I've taken the time to explain my opinions, and they're fairly well-informed: I use Git daily, for real work, and I used Subversion for many years. Moreover, my opinion is fairly measured: I can see the value of Git -- just not for most types of non-distributed development. My direct experience with the system trumps whatever theories you have about the quality of the approach.
Maybe my experience is due to the way that I use version control; maybe I'm just not a "power" user. I don't know. All I really know is that if you can't a handle a civil discussion of a version control system without resorting to emotional retorts, then you're WAY too invested in the debate.
OK, then you'd better not use any revision control at all -- any local checkout is also a branch. You can make changes to your working copy, and nobody will ever see them. I know people that have avoided committing for days because we had a policy against branching, and they needed to do a very extensive refactoring. What a helpful policy! At least we didn't have to maintain a branch...
The fun continues. When you do an "svn update", that's a merge. Except, it's a lossy merge that is happy to throw data away. If there are merge conflicts, you don't have the opportunity to say, "oh shit, fuck this update, just give me my files back". Your data is gone, sucker, so fix those conflicts right now!
Git, in contrast, does not suffer from this problem. It won't let you merge when the index is dirty. ("git stash" is a nice way to cleanup the index without losing any data, if you Have To Merge Right Now). When you merge and there are conflicts, you have a variety of options. You can forget the merge ever happened, you can fix it, or some combination thereof. Without branches, that wouldn't be possible.
Anyway, I'm glad I don't work somewhere with "project managers". I don't need people micromanaging my coding, nor does anyone else.
(If you don't like Git, just say you don't like Git. But there is no need to make up an imaginary entity who is arguing against it, because that's just silly.)
Developers work in branches to keep developmental code out of their "stable" or "deployment-ready" code.
In fact, development is almost guaranteed to move slower if you only use one branch, because half of your time would be consumed with making sure you haven't broken the original code instead of being able to focus on the new feature.
I still think this post is a joke, though. Developers branch because they're being cautious and project managers don't care how you develop as long as you're delivering on time, basically the exact opposite of what you've stated.