4 ms·

> I'm almost certain if it weren't Torvalds, it would be someone else who creates something like Git. He just had the need and skills to create it. Like Bill Ga

> I'm almost certain if it weren't Torvalds, it would be someone else who creates something like Git. He just had the need and skills to create it. Like Bill Gates he was just a competent person, at the right place and time. I think it's fair to point out that Torvalds didn't come up with Git on his own - he was influenced by a good amount of prior art, not the least of which was Bitkeeper. However, I think calling him a "competent person, at the right place and time" undersells him to a substantial degree. 1. He's a world class software developer. 2. He's a world class tech lead (There are certainly criticisms about his communication style, which I don't think are unfair. Here, I am judging him by the artifacts created under his leadership). 3. He was the write lock for an extremely large distributed team for more than a decade. It is not surprising to me that the 2nd most famous distributed source control tool - Mercurial - was also initially created by a Linux kernel developer.

deleted 6y ago
[deleted]
bch 6y ago
> It is not surprising to me that the 2nd most famous distributed source control tool - Mercurial - was also initially created by a Linux kernel developer. Because Linux was in a crisis and hot off an excellent experience w bitkeeper? Or something more profound?
- edoceo 6y ago
  Maybe their extensive experience with both big-system code and distributed team problems?
- nordsieck 6y ago
  > Because Linux was in a crisis and hot off an excellent experience w bitkeeper? Or something more profound? I'm sure the crisis was part of it. But also, the way Linux development is organized is very weird compared to how code is developed in most places. "Distributed" is not quite right, but it's the best word I've got. A source control tool like Perforce just wouldn't fit linux development very well, whereas large companies at the time were perfectly happy with it.
  - quicklime 6y ago
    “Decentralized”? I agree with you that Linux development is weird compared to most places. Most places have a designated central repo that acts as the source of truth, whereas the Linux developers don’t really have this. This is possibly an unpopular opinion, but I think that when there is an official main repo, git is far more complicated than it needs to be. It’s confusing to a lot of developers because of all this unnecessary complexity. Most teams could probably be served better by a simpler system.
    - Koromix 6y ago
      I share this opinion as well. For centralized-repo style, which is what most teams need, the Git model has three problems: - It is hard to use. There's a reason most teams have a single or two Git "experts" to help everyone else resolve repository / merge / pull / whatever problems that happen regularly. The onboarding experience for developers unfamilir with Git is very bad, and many of them end up never able to use it. If you have non-developers (e.g. artists), it is even worse. - Binary files. Yes, there is Git LFS, but there are many small integration problems when you try to use it, and the simple fact that Git needs something special to manage binary files is a problem. And no, storing binary files outside the repository is NOT a good solution. In games for example, the binary files and the engine usually evole together and if you want to checkout an old version, the code and the assets need to stay in sync. You want to version the game, not just the engine. - Partial (subtree) clones and permissions. There's a reason monorepos are popular: they're much simpler to manage. Unfortunaly, because Git barely does partial clones and cannot manage permissions (inside a repository) at all, monorepos are much more limited than in SVN or P4. That's why many projects end up divided in multiple repos, but this brings all sorts of problems and a large administrative overhead for all developers.
      - nix23 6y ago
        Give bitkeeper a try, it's now FOSS -Simple clean interface -You can work the linux way or with a central-repo-style -Binary Asset Manager build in -Nested (submodules done right)

deleted 6y ago

[deleted]

bch 6y ago

> It is not surprising to me that the 2nd most famous distributed source control tool - Mercurial - was also initially created by a Linux kernel developer. Because Linux was in a crisis and hot off an excellent experience w bitkeeper? Or something more profound?

edoceo 6y ago
Maybe their extensive experience with both big-system code and distributed team problems?
nordsieck 6y ago
> Because Linux was in a crisis and hot off an excellent experience w bitkeeper? Or something more profound? I'm sure the crisis was part of it. But also, the way Linux development is organized is very weird compared to how code is developed in most places. "Distributed" is not quite right, but it's the best word I've got. A source control tool like Perforce just wouldn't fit linux development very well, whereas large companies at the time were perfectly happy with it.
- quicklime 6y ago
  “Decentralized”? I agree with you that Linux development is weird compared to most places. Most places have a designated central repo that acts as the source of truth, whereas the Linux developers don’t really have this. This is possibly an unpopular opinion, but I think that when there is an official main repo, git is far more complicated than it needs to be. It’s confusing to a lot of developers because of all this unnecessary complexity. Most teams could probably be served better by a simpler system.
  - Koromix 6y ago
    I share this opinion as well. For centralized-repo style, which is what most teams need, the Git model has three problems: - It is hard to use. There's a reason most teams have a single or two Git "experts" to help everyone else resolve repository / merge / pull / whatever problems that happen regularly. The onboarding experience for developers unfamilir with Git is very bad, and many of them end up never able to use it. If you have non-developers (e.g. artists), it is even worse. - Binary files. Yes, there is Git LFS, but there are many small integration problems when you try to use it, and the simple fact that Git needs something special to manage binary files is a problem. And no, storing binary files outside the repository is NOT a good solution. In games for example, the binary files and the engine usually evole together and if you want to checkout an old version, the code and the assets need to stay in sync. You want to version the game, not just the engine. - Partial (subtree) clones and permissions. There's a reason monorepos are popular: they're much simpler to manage. Unfortunaly, because Git barely does partial clones and cannot manage permissions (inside a repository) at all, monorepos are much more limited than in SVN or P4. That's why many projects end up divided in multiple repos, but this brings all sorts of problems and a large administrative overhead for all developers.
    - nix23 6y ago
      Give bitkeeper a try, it's now FOSS -Simple clean interface -You can work the linux way or with a central-repo-style -Binary Asset Manager build in -Nested (submodules done right)