5 ms·

This article by John Coggeshall is an example of great technical writing. I look forward to reading more of his work. The more I learn about Git, the more it b

This article by John Coggeshall is an example of great technical writing. I look forward to reading more of his work. The more I learn about Git, the more it blows my mind. Torvalds must have designed Git in his head during the time he was using BitKeeper. When he decided to implement Git, he went to work and in a few weeks he had it working well enough to use for Linux kernel source control. Torvalds is either a genius or merely a superstar computer scientist and software engineer. Choose any two.

langitbiru 6y ago
10x engineer? :)
nujabe 6y ago
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.
- nordsieck 6y ago
  > 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.
- kohtatsu 6y ago
  I'd love to see an in-depth comparison of the contributions to technology from Jobs, Gates, and Torvalds.
  - nix23 6y ago
    I dont think there is much: -Jobs was management -Gates made basic and management -Torvald made a VCS a Kernel a Divecomputer-programm and a new way to develop software
- riquito 6y ago
  > "He just had the need and skills to create it" Yeah, lucky Linus /sarcasm A bit undeserving, don't you think?
- Dylan16807 6y ago
  If? Is Mercurial not like Git?
  - addicted 6y ago
    Yes, and according to Wikipedia their initial releases were only 2 weeks apart. Further, you also had Bazaar whose initial release was a month earlier and was itself based on another tool that was released a year before. For whatever reason, creating distributed alternatives to SVN was a very popular thing to do at the time.
    - Volt 6y ago
      They were really meant to be FLOSS alternatives to BitKeeper, not SVN.
- rumanator 6y ago
  > he was just a competent person, at the right place and time. If you honestly have that pov then it must be very hard to explain how no one else in the whole history of the world has ever managed to pull anything similar to Git. It's one thing to point out we all stand on the shoulders of giants, but it's an entirely different thing to claim any random person with average skills pulls this off. I mean where's your Git?
  - deleted 6y ago
    [deleted]
- sradman 6y ago
  > ... he was just a competent person, at the right place and time. Right skill set, right place, right time. The decentralized team workflow of Open Source projects demanded a decentralized version control system (DVCS). A number of DVCS systems emerged with varying trade-offs. It is interesting, but non obvious, which set of trade-offs gain greater adoption. Git versus Mercurial is a case study of this process.
magnio 6y ago
Reading the first Git version, i.e. its initial commit, makes learning git easier for me. Albeit very simple and barebone, its ideas are pretty fundamental to Git and differentiate it from many other VCSs.
beagle3 6y ago
Everyone is forgetting “monotone”, a DVCS developed by Graydon Hoare (who later went to create Rust) of which the Git model is essentially a simplification (and much much less related to BitKeeper) There was a lot of experimentation with VCSes at the time: arch -> tla -> baz ; bzr ; monotone ; cdv ; mercurial ; git ; even sun was finally getting merge tracking. Monotone had the best structure but a slow and clunky implementation. It was adopted and simplified (in different ways) by git and hg; eventually git won by virtue of being way faster and demonstrably effective for a project the size of the Linux kernel (and Linus’ celebrity status didn’t hurt either) But graydon hoare deserves a lot more credit than he received - Linus did credit him at the time, but no one seems to remember.
- nix23 6y ago
  >Everyone is forgetting “monotone” I miss monotone! What a beautiful single-file (sqlite) VCS if it would be still maintained i would use it for small projects, but nowadays i use fossil and bitkeeper...and yeah git if i have to ;)
  - SQLite 6y ago
    Author of SQLite and Fossil here - I have not forgotten monotone! Indeed, Fossil itself is inspired by monotone documentation (though not the implementation). This is credited at https://fossil-scm.org/fossil/doc/trunk/www/history.md https://fossil-scm.org/fossil/doc/trunk/www/history.md
    - nix23 6y ago
      Thank you very much for that great piece's of Software!! Both Fossil and SQLite.
    - dschulz 6y ago
      Dr. Richard Hipp? Thanks for all your work. The world is a significantly better place thanks to you.
  - the_pwner224 6y ago
alblue 6y ago
I wrote a series of blog posts covering how the intervals of git works; I posted a summary here for reference: https://alblue.bandlem.com/2011/12/git-tip-of-week-finale.html https://alblue.bandlem.com/2011/12/git-tip-of-week-finale.ht... If you’re interested in how commits, trees and objects are represented then it could be interesting for you.
chmaynard 6y ago
“The thing that differentiates scientists is purely an artistic ability to discern what is a good idea, what is a beautiful idea, what is worth spending time on, and most importantly, what is a problem that is sufficiently interesting, yet sufficiently difficult, that it hasn't yet been solved, but the time for solving it has come now.” -- Savas Dimopoulos

langitbiru 6y ago

10x engineer? :)

nujabe 6y ago

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.

nordsieck 6y ago
> 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.
kohtatsu 6y ago
I'd love to see an in-depth comparison of the contributions to technology from Jobs, Gates, and Torvalds.
- nix23 6y ago
  I dont think there is much: -Jobs was management -Gates made basic and management -Torvald made a VCS a Kernel a Divecomputer-programm and a new way to develop software
riquito 6y ago
> "He just had the need and skills to create it" Yeah, lucky Linus /sarcasm A bit undeserving, don't you think?
Dylan16807 6y ago
If? Is Mercurial not like Git?
- addicted 6y ago
  Yes, and according to Wikipedia their initial releases were only 2 weeks apart. Further, you also had Bazaar whose initial release was a month earlier and was itself based on another tool that was released a year before. For whatever reason, creating distributed alternatives to SVN was a very popular thing to do at the time.
  - Volt 6y ago
    They were really meant to be FLOSS alternatives to BitKeeper, not SVN.
rumanator 6y ago
> he was just a competent person, at the right place and time. If you honestly have that pov then it must be very hard to explain how no one else in the whole history of the world has ever managed to pull anything similar to Git. It's one thing to point out we all stand on the shoulders of giants, but it's an entirely different thing to claim any random person with average skills pulls this off. I mean where's your Git?
- deleted 6y ago
  [deleted]
sradman 6y ago
> ... he was just a competent person, at the right place and time. Right skill set, right place, right time. The decentralized team workflow of Open Source projects demanded a decentralized version control system (DVCS). A number of DVCS systems emerged with varying trade-offs. It is interesting, but non obvious, which set of trade-offs gain greater adoption. Git versus Mercurial is a case study of this process.

magnio 6y ago

Reading the first Git version, i.e. its initial commit, makes learning git easier for me. Albeit very simple and barebone, its ideas are pretty fundamental to Git and differentiate it from many other VCSs.

beagle3 6y ago

Everyone is forgetting “monotone”, a DVCS developed by Graydon Hoare (who later went to create Rust) of which the Git model is essentially a simplification (and much much less related to BitKeeper) There was a lot of experimentation with VCSes at the time: arch -> tla -> baz ; bzr ; monotone ; cdv ; mercurial ; git ; even sun was finally getting merge tracking. Monotone had the best structure but a slow and clunky implementation. It was adopted and simplified (in different ways) by git and hg; eventually git won by virtue of being way faster and demonstrably effective for a project the size of the Linux kernel (and Linus’ celebrity status didn’t hurt either) But graydon hoare deserves a lot more credit than he received - Linus did credit him at the time, but no one seems to remember.

nix23 6y ago
>Everyone is forgetting “monotone” I miss monotone! What a beautiful single-file (sqlite) VCS if it would be still maintained i would use it for small projects, but nowadays i use fossil and bitkeeper...and yeah git if i have to ;)
- SQLite 6y ago
  Author of SQLite and Fossil here - I have not forgotten monotone! Indeed, Fossil itself is inspired by monotone documentation (though not the implementation). This is credited at https://fossil-scm.org/fossil/doc/trunk/www/history.md https://fossil-scm.org/fossil/doc/trunk/www/history.md
  - nix23 6y ago
    Thank you very much for that great piece's of Software!! Both Fossil and SQLite.
  - dschulz 6y ago
    Dr. Richard Hipp? Thanks for all your work. The world is a significantly better place thanks to you.
- the_pwner224 6y ago

alblue 6y ago

I wrote a series of blog posts covering how the intervals of git works; I posted a summary here for reference: https://alblue.bandlem.com/2011/12/git-tip-of-week-finale.html https://alblue.bandlem.com/2011/12/git-tip-of-week-finale.ht... If you’re interested in how commits, trees and objects are represented then it could be interesting for you.

chmaynard 6y ago

“The thing that differentiates scientists is purely an artistic ability to discern what is a good idea, what is a beautiful idea, what is worth spending time on, and most importantly, what is a problem that is sufficiently interesting, yet sufficiently difficult, that it hasn't yet been solved, but the time for solving it has come now.” -- Savas Dimopoulos