6 ms·

Well, he did create git. Not that your point isn't valid, just pointing out Linus is actively helping forward progress.

rpledge 16y ago
Excellent point, git is certainly innovative. It's a great example of someone smart seeing a problem with his workflow and fixing it (although this isn't 100% what happened, the whole bitkeeper/closed source debacle played a hand). I guess my point is that I haven't seen too much development in the core kernel lately, especially wrt helping use multicore better.
tbrownaw 16y ago
Not sure I'd call intertwingling the repository/workspace like that, or conflating branches and repositories, "progress". But I suppose it's better than svn/cvs/etc that it's largely taking its users from. (disclaimer: I work on a VCS that's written in C++ and uses a real database, nice object-oriented libraries, and nice C++ abstractions :)
- shadytrees 16y ago
  > (disclaimer: I work on a VCS that's written in C++ and uses a real database, nice object-oriented libraries, and nice C++ abstractions :) Wait, you can't just write that and end your comment! What VCS do you work on?, if you're at liberty to share.
  - tbrownaw 16y ago
    I work on monotone ( http://monotone.ca/ http://monotone.ca/ ) which is older and I think conceptually cleaner, and that was a reference to this earlier rant (last paragraph): http://lwn.net/Articles/249460/ http://lwn.net/Articles/249460/ . We've also gotten a few comments about the code being very nice, so I doubt it's really all that messy and unmaintainable.
- chousuke 16y ago
  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.

Excellent point, git is certainly innovative. It's a great example of someone smart seeing a problem with his workflow and fixing it (although this isn't 100% what happened, the whole bitkeeper/closed source debacle played a hand). I guess my point is that I haven't seen too much development in the core kernel lately, especially wrt helping use multicore better.

tbrownaw 16y ago

Not sure I'd call intertwingling the repository/workspace like that, or conflating branches and repositories, "progress". But I suppose it's better than svn/cvs/etc that it's largely taking its users from. (disclaimer: I work on a VCS that's written in C++ and uses a real database, nice object-oriented libraries, and nice C++ abstractions :)

shadytrees 16y ago
> (disclaimer: I work on a VCS that's written in C++ and uses a real database, nice object-oriented libraries, and nice C++ abstractions :) Wait, you can't just write that and end your comment! What VCS do you work on?, if you're at liberty to share.
- tbrownaw 16y ago
  I work on monotone ( http://monotone.ca/ http://monotone.ca/ ) which is older and I think conceptually cleaner, and that was a reference to this earlier rant (last paragraph): http://lwn.net/Articles/249460/ http://lwn.net/Articles/249460/ . We've also gotten a few comments about the code being very nice, so I doubt it's really all that messy and unmaintainable.
chousuke 16y ago
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.