5 ms·

I don't like branches either (we've been using git for maybe a year now at justin.tv, so I've definitely had the opportunity to grow to like them). Actually I

I don't like branches either (we've been using git for maybe a year now at justin.tv, so I've definitely had the opportunity to grow to like them). Actually I think one of the biggest reasons I don't like them is that they're a kind of "hidden state". If someone made a VCS (or just an interface to an existing VCS) where branches were just represented by different subdirectories in the filesystem, then I might use them more.

blasdel 17y ago
You can do that just fine with git: just make multiple independent checkouts in the filesystem. I do it all the time.
spolsky 17y ago
that's how it works in Mercurial, if you make your branches by cloning.
lutorm 17y ago
That is how branching works in svn, you make a copy to another directory on the repository.
- abstractbill 17y ago
  I know how svn branching works - I don't think I explained myself clearly. I'd love a RCS that would let me see every branch that currently exists without having to check them out. The branches would exist as directories on my local filesystem. Any file operations (doing a directory listing, or accessing a file) on these local directories would actually be doing RCS commands and pulling data over the network, but I wouldn't have to think about that anymore.
  - lutorm 17y ago
    If you checkout the svn root, you get all the branches as directories in your local filesystem. After that, it seems it would be the same as what you're saying. Besides, you can do svn ls to see the branches. I must be missing what you're getting at.
    - LaPingvino 17y ago
      I think he means that the way you work is the same as in SVN but the way the system works is like Git etc.: the branches are editable and accessible like directories but with the advantages and changeset-construction of Git behind it. Am I right?
axod 17y ago
For me it's mainly as you said on another comment... The overhead of managing and switching between branches is just too big a price, for no gain that I can see. I have a hard enough time remembering the state of a single trunk, let alone if I had several branches on the go at a time. I'd fail spectacularly at remembering which branch has what on it... It's easier to just do: * Never break the build / functionality of code (Good idea anyway) * Architect your stuff well with minimal dependencies so you can can swap in/out modules/components easily. Personally, I feel branching+merging is as much use/fun as filling out TPS reports.

blasdel 17y ago

You can do that just fine with git: just make multiple independent checkouts in the filesystem. I do it all the time.

spolsky 17y ago

that's how it works in Mercurial, if you make your branches by cloning.

lutorm 17y ago

That is how branching works in svn, you make a copy to another directory on the repository.

abstractbill 17y ago
I know how svn branching works - I don't think I explained myself clearly. I'd love a RCS that would let me see every branch that currently exists without having to check them out. The branches would exist as directories on my local filesystem. Any file operations (doing a directory listing, or accessing a file) on these local directories would actually be doing RCS commands and pulling data over the network, but I wouldn't have to think about that anymore.
- lutorm 17y ago
  If you checkout the svn root, you get all the branches as directories in your local filesystem. After that, it seems it would be the same as what you're saying. Besides, you can do svn ls to see the branches. I must be missing what you're getting at.
  - LaPingvino 17y ago
    I think he means that the way you work is the same as in SVN but the way the system works is like Git etc.: the branches are editable and accessible like directories but with the advantages and changeset-construction of Git behind it. Am I right?

axod 17y ago

For me it's mainly as you said on another comment... The overhead of managing and switching between branches is just too big a price, for no gain that I can see. I have a hard enough time remembering the state of a single trunk, let alone if I had several branches on the go at a time. I'd fail spectacularly at remembering which branch has what on it... It's easier to just do: * Never break the build / functionality of code (Good idea anyway) * Architect your stuff well with minimal dependencies so you can can swap in/out modules/components easily. Personally, I feel branching+merging is as much use/fun as filling out TPS reports.