7 ms·

I'm not sure emphasizing how much easier branching is in Git is a good idea. Git already has a "herding cats" kind of reputation. Programmers like branching be

by cosmo7 18y ago

I'm not sure emphasizing how much easier branching is in Git is a good idea. Git already has a "herding cats" kind of reputation. 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.

nuclear_eclipse 18y ago
> 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."
- tptacek 18y ago
  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.
  - rmaccloy 18y ago
    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.
    - tptacek 18y ago
      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.
      - jrockway 18y ago
        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.
        timr 18y ago
timr 18y ago
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.
- rmaccloy 18y ago
  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.
  - timr 18y ago
    "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.
    - rmaccloy 18y ago
      '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.
jrockway 18y ago
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.)
pjhyett 18y ago
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.

by cosmo7 18y ago

nuclear_eclipse 18y ago

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

tptacek 18y ago
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.
- rmaccloy 18y ago
  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.
  - tptacek 18y ago
    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.
    - jrockway 18y ago
      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.
      - timr 18y ago

timr 18y ago

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.

rmaccloy 18y ago
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.
- timr 18y ago
  "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.
  - rmaccloy 18y ago
    '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.

jrockway 18y ago

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

pjhyett 18y ago

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.