4 ms·

The advantage of having lots of small branches is that you isolate work. You never have the problem of wanting to fix a bug or add some small feature, but havin

The advantage of having lots of small branches is that you isolate work. You never have the problem of wanting to fix a bug or add some small feature, but having the code all in a mess halfway through a major reorganization. Also it's a lot easier to try something experimental on a branch. If it works, merge it in. If it fails, abandon the branch. Git makes branching and merging fast enough that using them as the default workflow makes sense.

axod 17y ago
Yeah I just don't work that way. I work linearly :/
- dasil003 17y ago
  What type of work do you do that you never have urgent bug fixes and/or never have features that take more than a day to complete? Sure it's optimal to work linearly, but in the real world things come up. Now if you are looking for a reason to tell stakeholders to suck it up and wait, then poor branching support may help you, but that's a technical solution to a managerial problem. If you're interested in having the most flexibility to solve real world problems, then git's power is indispensable. Hell, you can work linearly all the time, and retroactively convert anything into a branch. Even if you don't need branches. Even if you are the sole developer. Sorry if that's a little harsh, but statements like "My point is, if you want lightening fast rev control for some reason, probably better to not use distributed." smack of willful ignorance. Go use git for a while and then come back and try to say that with a straight face.
  - tentonova 17y ago
    What type of work do you do that you never have urgent bug fixes and/or never have features that take more than a day to complete? I've always worked to constrain non-linear development to the absolute minimum required because the technical costs are easily dwarfed by the human communication overhead and inherent organizational complexity engendered in multiple disparate branches of development.
    - dasil003 17y ago
      Of course, but that's irrelevant to the utility of git branches. In subversion, yes, you don't go through the hassle of creating a branch for all these reasons. In git though, branches are most commonly used within one developer's workflow. The vast majority of branches are never seen by more than one developer, they are simply an organizational tool to be used at your discretion without imposing any overhead on anyone unless you have good reason to.
      - tentonova 17y ago
        In subversion, yes, you don't go through the hassle of creating a branch for all these reasons. svn cp ^/trunk ^/branches/tentonova-bugfix-x svn co ^/branches/tentonova ~/branch I wouldn't call this a technical "hassle", and I'm not sure what organizational issues would arise here. The vast majority of branches are never seen by more than one developer, they are simply an organizational tool to be used at your discretion without imposing any overhead on anyone unless you have good reason to. Hiding your development branches on a shared codebase often incurs either communication overhead, or the costs of lack of communication.
        prodigal_erik 17y ago
        We do that, and I will say that svnmerge.py doesn't work very well with older versions of svn. A common failure mode is when you merge from trunk to rebase a dev branch and find a conflict, your edits to resolve it are automatically ignored and not reflected back to trunk, and any overlapping edits you make later will eventually cause new conflicts when you finally go to trunk. Apparently the new svn:mergeinfo property helps, but we haven't migrated at work so I don't know how well.
        dasil003 17y ago
        I wouldn't call this a technical "hassle", and I'm not sure what organizational issues would arise here. Merging. Hiding your development branches on a shared codebase often incurs either communication overhead, or the costs of lack of communication. If you're using the limitations of your VCS to manage team communication then you have bigger problems. The obvious analog to the "problem" you mention is people not checking in code because it's not ready yet. Maybe you think this is better because you only want deployable software in your main branch, but for large features that makes the history opaque and leaves your developer effectively without any of the benefits of version control while they are working on the large feature. Frankly, a lot of the arguments against DVCS smack of the same sort of ignorance that the Java zealots were leveraging against Ruby back when Rails started picking up steam in 2005/2006. There's this fear that powerful features will lead to chaos and are in effect too powerful to be used safely. And the reality is that yes, in environments truly incompetent programmers work, there's definitely a strong argument to be made for limiting the damage they can do. But I think the past few years have borne out the fact that mediocre and merely-competent programmers can make strong use of these tools without leading to disaster.
  - axod 17y ago
    I have many features that take more than a day to complete, but I prefer to do them in such a way that it doesn't break other stuff. That's just the way I prefer to work. If I'm working through a big arch change, I'll do it in sections, each time making sure everything builds and works and is sane. I checkin often, once I hit something that builds+works. That's just the way I work. Similarly, I don't use threads in programs unless I absolutely categorically have to. It's a similar sort of thing. Call me crazy :/ I did use git for a bit, and thought 'meh'. It didn't solve any real world problem I had.

axod 17y ago

Yeah I just don't work that way. I work linearly :/

dasil003 17y ago
What type of work do you do that you never have urgent bug fixes and/or never have features that take more than a day to complete? Sure it's optimal to work linearly, but in the real world things come up. Now if you are looking for a reason to tell stakeholders to suck it up and wait, then poor branching support may help you, but that's a technical solution to a managerial problem. If you're interested in having the most flexibility to solve real world problems, then git's power is indispensable. Hell, you can work linearly all the time, and retroactively convert anything into a branch. Even if you don't need branches. Even if you are the sole developer. Sorry if that's a little harsh, but statements like "My point is, if you want lightening fast rev control for some reason, probably better to not use distributed." smack of willful ignorance. Go use git for a while and then come back and try to say that with a straight face.
- tentonova 17y ago
  What type of work do you do that you never have urgent bug fixes and/or never have features that take more than a day to complete? I've always worked to constrain non-linear development to the absolute minimum required because the technical costs are easily dwarfed by the human communication overhead and inherent organizational complexity engendered in multiple disparate branches of development.
  - dasil003 17y ago
    Of course, but that's irrelevant to the utility of git branches. In subversion, yes, you don't go through the hassle of creating a branch for all these reasons. In git though, branches are most commonly used within one developer's workflow. The vast majority of branches are never seen by more than one developer, they are simply an organizational tool to be used at your discretion without imposing any overhead on anyone unless you have good reason to.
    - tentonova 17y ago
      In subversion, yes, you don't go through the hassle of creating a branch for all these reasons. svn cp ^/trunk ^/branches/tentonova-bugfix-x svn co ^/branches/tentonova ~/branch I wouldn't call this a technical "hassle", and I'm not sure what organizational issues would arise here. The vast majority of branches are never seen by more than one developer, they are simply an organizational tool to be used at your discretion without imposing any overhead on anyone unless you have good reason to. Hiding your development branches on a shared codebase often incurs either communication overhead, or the costs of lack of communication.
      - prodigal_erik 17y ago
        We do that, and I will say that svnmerge.py doesn't work very well with older versions of svn. A common failure mode is when you merge from trunk to rebase a dev branch and find a conflict, your edits to resolve it are automatically ignored and not reflected back to trunk, and any overlapping edits you make later will eventually cause new conflicts when you finally go to trunk. Apparently the new svn:mergeinfo property helps, but we haven't migrated at work so I don't know how well.
      - dasil003 17y ago
        I wouldn't call this a technical "hassle", and I'm not sure what organizational issues would arise here. Merging. Hiding your development branches on a shared codebase often incurs either communication overhead, or the costs of lack of communication. If you're using the limitations of your VCS to manage team communication then you have bigger problems. The obvious analog to the "problem" you mention is people not checking in code because it's not ready yet. Maybe you think this is better because you only want deployable software in your main branch, but for large features that makes the history opaque and leaves your developer effectively without any of the benefits of version control while they are working on the large feature. Frankly, a lot of the arguments against DVCS smack of the same sort of ignorance that the Java zealots were leveraging against Ruby back when Rails started picking up steam in 2005/2006. There's this fear that powerful features will lead to chaos and are in effect too powerful to be used safely. And the reality is that yes, in environments truly incompetent programmers work, there's definitely a strong argument to be made for limiting the damage they can do. But I think the past few years have borne out the fact that mediocre and merely-competent programmers can make strong use of these tools without leading to disaster.
- axod 17y ago
  I have many features that take more than a day to complete, but I prefer to do them in such a way that it doesn't break other stuff. That's just the way I prefer to work. If I'm working through a big arch change, I'll do it in sections, each time making sure everything builds and works and is sane. I checkin often, once I hit something that builds+works. That's just the way I work. Similarly, I don't use threads in programs unless I absolutely categorically have to. It's a similar sort of thing. Call me crazy :/ I did use git for a bit, and thought 'meh'. It didn't solve any real world problem I had.