6 ms·

True, I don't really like using branching/merging as a workflow unless absolutely necessary. So sure, if you're constantly branching and merging all day, then I

by axod 17y ago

True, I don't really like using branching/merging as a workflow unless absolutely necessary. So sure, if you're constantly branching and merging all day, then I can see it being a problem. But I'm not convinced branching+merging is really good for your productivity. The other point is that with a distributed system like git, all of the load is on your local machine. With a centralized system like subversion, the server could do the heavy lifting (Wether this happens in practice is another matter). My point is, if you want lightening fast rev control for some reason, probably better to not use distributed.

silentbicycle 17y ago
The flip side is that, with most VC systems, queries about changes or repository history have network latency added. The feedback is near-instant from distributed systems, which keep their info locally. I find it makes a tremendous difference when, say, bisecting an error.
DougBTX 17y ago
But I'm not convinced branching+merging is really good for your productivity. Because branching and merging are slow? I can see this argument getting stuck in something of a rut.
- axod 17y ago
  No. I prefer to keep things simple, always make sure the source builds, and just develop linearly where possible. I think it makes for cleaner workflow.
  - JulianMorrison 17y ago
    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.

by axod 17y ago

silentbicycle 17y ago

The flip side is that, with most VC systems, queries about changes or repository history have network latency added. The feedback is near-instant from distributed systems, which keep their info locally. I find it makes a tremendous difference when, say, bisecting an error.

DougBTX 17y ago

But I'm not convinced branching+merging is really good for your productivity. Because branching and merging are slow? I can see this argument getting stuck in something of a rut.

axod 17y ago
No. I prefer to keep things simple, always make sure the source builds, and just develop linearly where possible. I think it makes for cleaner workflow.
- JulianMorrison 17y ago
  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.