3 ms·

The repository/workspace issue I can agree with (though there is an environment variable that you can use to specify a repository outside the current directory)

The repository/workspace issue I can agree with (though there is an environment variable that you can use to specify a repository outside the current directory), but what do you mean with "conflating branches and repositories"? In git, branches are not a special entity. They are a property of the contents of the repository. The commits form a DAG, which is also a tree, and trees often have branches. A repository might have dozens of branch points that are never referenced by name, but that doesn't mean they don't exist. You can even consider the whole set of repositories for a single project as forming a logical DAG in this manner. However, because of the distributed nature of git, there will be branches that are not visible to you. Given this, what does it mean to somehow "separate" the concept of repositories from branches?

tbrownaw 16y ago
Perhaps a better way of saying that would be that they picked a very unique (re-)definition of what a branch is (something like "pair<repository * , commit * repository::*>"). I tend to think of a branch more as "a buch of commits that go together", which seems to fit very nicely with common usage where you have a release branch, dev branch, etc. It just seems very bizzare that people working on the "dev branch" are actually working on entirely separate branches just because they're in different offices which use separate local mirrors in case the internet breaks.
- chousuke 16y ago
  If git has defined 'branch' to mean something different from other VCS, then I think git got it right and everyone else is wrong. The distributed nature of git (and any DVCS) means developers on the 'dev branch' are working on different branches, even if they all call it 'dev' in their local repositories. Their local development may have started from the same parent, but it's not the same branch. If you send the commits to someone else, they'll be completely separate from the receiver's dev branch until merged. It seems to me that your idea of the "dev branch" is in git a purely non-technical thing. That is, a branch in some blessed repository that points to the so-far merged efforts of all the developers' dev branches, representing 'current' development. I think this is a good thing, and I'm yet to be convinced otherwise.

tbrownaw 16y ago

Perhaps a better way of saying that would be that they picked a very unique (re-)definition of what a branch is (something like "pair<repository * , commit * repository::*>"). I tend to think of a branch more as "a buch of commits that go together", which seems to fit very nicely with common usage where you have a release branch, dev branch, etc. It just seems very bizzare that people working on the "dev branch" are actually working on entirely separate branches just because they're in different offices which use separate local mirrors in case the internet breaks.

chousuke 16y ago
If git has defined 'branch' to mean something different from other VCS, then I think git got it right and everyone else is wrong. The distributed nature of git (and any DVCS) means developers on the 'dev branch' are working on different branches, even if they all call it 'dev' in their local repositories. Their local development may have started from the same parent, but it's not the same branch. If you send the commits to someone else, they'll be completely separate from the receiver's dev branch until merged. It seems to me that your idea of the "dev branch" is in git a purely non-technical thing. That is, a branch in some blessed repository that points to the so-far merged efforts of all the developers' dev branches, representing 'current' development. I think this is a good thing, and I'm yet to be convinced otherwise.