4 ms·

As someone who has lived in Git for the past decade, I also fail to see why Git is a crappy design. It's easy to distribute, works well, and there's nothing wro

As someone who has lived in Git for the past decade, I also fail to see why Git is a crappy design. It's easy to distribute, works well, and there's nothing wrong with a tarball server.

trhway 2y ago
Exactly. While the article is good about events history, it doesn't go deep enough into the feature evolution (which is tightly connected to and reflects the evolution of the software development). Which is : TeamWare - somewhat easy branching (by copying whole workspace from the parent and the bringover/putback of the changes, good merge tool), the history is local, partial commits. BitKeeper added distributed mode, changesets. Git added very easy branching, stash, etc. Any other currently available source control usually is missing at least one of those features. Very illustrative is the case of Mercurial which emerged at about the same time responding to the same need for the modern source control at the time, yet was missing partial commits for example and had much cumbersome branching (like no local history or something like this - i looked at it last more than a decade ago) - that really allowed it to be used only in very strict/stuffy settings, for everybody else it was a non starter.
- nmz 2y ago
  Git is terrible at branching, constantly squashing and rebasing is not a feature but an annoyance. see fossil for how to do proper branching/merging/logging, by its very nature, Not to mention that by having the repository separate from the data, it forces you to organize it in a nice way (Mine look like Project/(repo.fossil, branch1/ branch2/ branch3/) You can achieve this with git now but I never had to think about it in fossil, its a natural consequence of the design.
  - trhway 2y ago
    >constantly squashing and rebasing is not a feature but an annoyance it is a feature which allows, for example, to work simultaneously on several releases, patches, hot fixes, etc. Once better alternative emerges we'll jump the git ship as we did before when we jumped onto the git ship. >the repository separate from the data that was a feature of a bunch of source controls and a reason among others why they lost to git. >it forces you to that is another reason why source controls lose to git as git isn't forcing some narrow way of doing things upon you. I don't deny of course that for some people/teams/projects other source controls work better as you comment illustrates. I'm just saying why git won and keeps the majority of situations.
    - nmz 2y ago
      > it is a feature which allows, for example, to work simultaneously on several releases, patches, hot fixes, etc. Once better alternative emerges we'll jump the git ship as we did before when we jumped onto the git ship. What are you talking about here? I'm not talking about eliminating branching, but the fact that merging a branch is usually just a fake single commit that hides away the complexity and decisions of the branch. see [0] into how you can leverage branches and the log for a sane commit history. > that was a feature of a bunch of source controls and a reason among others why they lost to git. Given the article, git won because it was foss, torvalds and speed, if you have proof of a good amount of people saying "I hate the division of data and repository!" then its a believable claim, or maybe you're confusing the data/repo division with cvs? git also didn't have to fight much, the only contender was hg [0]: https://fossil-scm.org/home/timeline https://fossil-scm.org/home/timeline
    - johannes1234321 2y ago
      > Once better alternative emerges we'll jump the git ship as we did before when we jumped onto the git ship. It's not that easy at this point in time. git carries a lot of momentum, especially in combination with GitHub. Anybody learning about software development learns about git and GitHub. Software is expected to be in GitHub. At the time git became successful there were arguably better systems like mercurial and now we got fossil, but git's shortcomings are too little of a pain point compared to universal knowledge about it and integration into every tool (any editor, any CI system, any package manager, ...) and process.
      - trhway 2y ago
        >It's not that easy at this point in time. git carries a lot of momentum, especially in combination with GitHub. CVS back then was like this too, including public repos, etc. >At the time git became successful there were arguably better systems like mercurial I specifically mentioned Mercurial above because they both emerged pretty simultaneously responding to the same challenges, and Mercurial happened to be just inferior due to its design choices. Companies were jumping onto it too, for example our management back then chose it, and it was a predictable huge pain in the neck, and some years down the road it was replaced with git.

As someone who has lived in Git for the past decade, I also fail to see why Git is a crappy design. It's easy to distribute, works well, and there's nothing wrong with a tarball server.

trhway 2y ago

Exactly. While the article is good about events history, it doesn't go deep enough into the feature evolution (which is tightly connected to and reflects the evolution of the software development). Which is : TeamWare - somewhat easy branching (by copying whole workspace from the parent and the bringover/putback of the changes, good merge tool), the history is local, partial commits. BitKeeper added distributed mode, changesets. Git added very easy branching, stash, etc. Any other currently available source control usually is missing at least one of those features. Very illustrative is the case of Mercurial which emerged at about the same time responding to the same need for the modern source control at the time, yet was missing partial commits for example and had much cumbersome branching (like no local history or something like this - i looked at it last more than a decade ago) - that really allowed it to be used only in very strict/stuffy settings, for everybody else it was a non starter.

nmz 2y ago
Git is terrible at branching, constantly squashing and rebasing is not a feature but an annoyance. see fossil for how to do proper branching/merging/logging, by its very nature, Not to mention that by having the repository separate from the data, it forces you to organize it in a nice way (Mine look like Project/(repo.fossil, branch1/ branch2/ branch3/) You can achieve this with git now but I never had to think about it in fossil, its a natural consequence of the design.
- trhway 2y ago
  >constantly squashing and rebasing is not a feature but an annoyance it is a feature which allows, for example, to work simultaneously on several releases, patches, hot fixes, etc. Once better alternative emerges we'll jump the git ship as we did before when we jumped onto the git ship. >the repository separate from the data that was a feature of a bunch of source controls and a reason among others why they lost to git. >it forces you to that is another reason why source controls lose to git as git isn't forcing some narrow way of doing things upon you. I don't deny of course that for some people/teams/projects other source controls work better as you comment illustrates. I'm just saying why git won and keeps the majority of situations.
  - nmz 2y ago
    > it is a feature which allows, for example, to work simultaneously on several releases, patches, hot fixes, etc. Once better alternative emerges we'll jump the git ship as we did before when we jumped onto the git ship. What are you talking about here? I'm not talking about eliminating branching, but the fact that merging a branch is usually just a fake single commit that hides away the complexity and decisions of the branch. see [0] into how you can leverage branches and the log for a sane commit history. > that was a feature of a bunch of source controls and a reason among others why they lost to git. Given the article, git won because it was foss, torvalds and speed, if you have proof of a good amount of people saying "I hate the division of data and repository!" then its a believable claim, or maybe you're confusing the data/repo division with cvs? git also didn't have to fight much, the only contender was hg [0]: https://fossil-scm.org/home/timeline https://fossil-scm.org/home/timeline
  - johannes1234321 2y ago
    > Once better alternative emerges we'll jump the git ship as we did before when we jumped onto the git ship. It's not that easy at this point in time. git carries a lot of momentum, especially in combination with GitHub. Anybody learning about software development learns about git and GitHub. Software is expected to be in GitHub. At the time git became successful there were arguably better systems like mercurial and now we got fossil, but git's shortcomings are too little of a pain point compared to universal knowledge about it and integration into every tool (any editor, any CI system, any package manager, ...) and process.
    - trhway 2y ago
      >It's not that easy at this point in time. git carries a lot of momentum, especially in combination with GitHub. CVS back then was like this too, including public repos, etc. >At the time git became successful there were arguably better systems like mercurial I specifically mentioned Mercurial above because they both emerged pretty simultaneously responding to the same challenges, and Mercurial happened to be just inferior due to its design choices. Companies were jumping onto it too, for example our management back then chose it, and it was a predictable huge pain in the neck, and some years down the road it was replaced with git.