Why we chose Git, a rebuttal(unethicalblogger.com)
unethicalblogger.com
Why we chose Git, a rebuttal
http://www.unethicalblogger.com/posts/2008/11/why_we_chose_git_a_rebuttal
4 comments
> 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."
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."
On the large commercial projects I've worked on, technology hasn't really been the problem with branching; even if you make branch-and-merge seamless, which nothing does, you still have to approve changes. That's harder to do with personal and ad-hoc branches, because there's no assurance that any planning went into the changes.
It's exactly the opposite in my experience: people will either commit untested junk to whatever the working tree is (usually trunk) or keep a bunch of untested code unversioned in their working copy and hopefully get it checked in at some point.
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.
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.
Without arguing the point, can you explain why merge is much, much easier with git? I just want to hear what things you bring up.
I like git, and use it, but I'll be honest and say the only thing "killer" about it for me is github.
I like git, and use it, but I'll be honest and say the only thing "killer" about it for me is github.
Without arguing the point, can you explain why merge is much, much easier with git? I just want to hear what things you bring up.
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.
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.
"Have you tried it? It just works more often than an svn merge."
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.
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.
How do you throw them away in svn? If you have changes in your working copy, you can't throw the merge away without throwing those away. Hence the pain.
So don't do that! There's absolutely no need to merge into a working copy with uncommitted changes (unless, of course, you're just looking for ways to break things). Check in your changes, then merge. It's not rocket surgery.
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.
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.
Check in your changes, then merge.
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.)
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 merging a branch into trunk, and your working copy of trunk is out of date, then you're still doing it wrong. Update, resolve conflicts, commit, then merge.
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.
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.
I could work around the problem, yes, but why bother when Git prevents this situation for me? A version control system shouldn't require me to manually backup the working copy to avoid losing my work.
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.
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.
As noted, the merge strategy(-ies) git uses is less prone to causing conflicts-- but TBH, you're always going to encounter some. (DVCSes in general produce fewer conflicts due to various tree merge shenanigans. Darcs and Codeville in particular have more interesting merge algorithms.)
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.
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.
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.
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.)
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.)
I don't agree with you that branches are unimportant, but I do agree that the emphasis on branching was a bit of a red herring.
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.
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.
The amount of FUD you've expelled about Git the last few days is suggesting to me that you got burned by it at some point. That sucks, but some of the stuff you've been saying is just flat-out wrong.
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.
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.
Oh, please...a guy expresses a critical opinion of your favorite version system, and he's automatically irrational and wrong? Are we debating religion or technology?
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.
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.
Branching is much, much more expensive in SVN than git (or any DVCS.) If you haven't grasped the immense value of cheap branches, nothing is going to make the inherent added complexity of DVCS (of which git has more than most, to be sure) sound good to you.
I branch at least several times a day when working on a project in git, and often throw them away quite soon afterward.
I branch at least several times a day when working on a project in git, and often throw them away quite soon afterward.
"If you haven't grasped the immense value of cheap branches..."
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.
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.
Why does every defense of Git seem to begin with a personal attack on the intelligence and knowledge of the critic?
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!?
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!?
all right, my argument against git is 1) no HTTP auth (ssh only) 2) no decent windows implementation
That's nice, but I don't think we are having that argument right now.
"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."
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.
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.
Thanks for reading the rest of my comment. Perhaps you should "take a step back, take a deep breath, and think a little harder".
'Grasped the immense value of...' isn't any more of a personal attack than 'apparently a lot of git users haven't heard...' :)
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.
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.
'Grasped the immense value of...' isn't any more of a personal attack than 'apparently a lot of git users haven't heard...'
Touché.
Touché.
A part of me wants to believe you're joking, because what you're saying about branching doesn't even make sense.
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.
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.
[deleted]
Wow, GIT fanboys are almost as smug and condescending as Apple fanboys. I wish I could un-read this post.
Sounds exactly like how I would answer the same question. Very rational.
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.