5 ms·

On the other hand, git became successful by being fast and by not solving certain of the hard theoretical problems that specialists were obsessed with solving.

by enqk 8y ago

On the other hand, git became successful by being fast and by not solving certain of the hard theoretical problems that specialists were obsessed with solving. It's hard to know before hand what the healthy compromise might be.

lobster_johnson 8y ago
git may have become successful, but that doesn't mean it's right. I'd argue that most developers still don't really understand git. I know seasoned, senior developers who struggle when git gets into an unfamiliar state, or who are completely mystified as to how it actually works. And don't forget that git spent years improving its initially horrific UI to make it easier and more palatable to people who aren't kernel developers. If you compare git to rival tools such as Mercurial and Fossil or even Darcs, it's pretty evident that git didn't really win on technical merit, user friendliness or indeed hardly any other metric. It was fast, and it had the dubious advantage of being better than a lot of crappy alternatives at the time, and of being the product of a famous developer. But if technical merit was how we chose software, we might all be using Mercurial today. It's quite possible we'd be better off, too. git's punting of "certain of the hard theoretical problems" lead to major shortcomings in its design. For example, git does not track branching histories. Once you merge your changes back into a branch and delete the origin branch, the path that your commits took are lost. Another example: Since git's data model works entirely on repository snapshots (there are no "patches" or logical operations, only snapshots), it doesn't know about file renames. Some commands, like log and diff, do understand how to detect renames (but not out of the box!), but it's fundamentally a fuzzy-matching operation that can only work perfectly if you separate your rename commits from modification commits, which is rarely feasible. Don't get me wrong, git has overall been a force for good, but I think it's a pretty terrible example in this particular case. In fact, I'm not sure I can think of many cases where the "worse is better" philosophy was ultimately a good idea. In every instance that comes to mind (MySQL, MongoDB, PHP), the fast-and-loose attitude ultimately came back to hurt everyone, and years were spent paying for those mistakes, plugging one hole at a time. The original decision by the Go team to build package management into the language ("go get") was made without really understanding the problem, and this decision has been haunting us pretty much since day one, with developers having to chase unofficial package management tools of the week in order to get their work done. I really want it to be done right, even if takes a bit longer. It's a problem worth solving well.
- paulsutter 8y ago
  Git isn’t ideal, but it is right. It’s right because it’s solving source code control for a huge percentage of software projects. Something better could be even more right, and adoption would be the measure. > git may have become successful, but that doesn't mean it's right.
  - kasey_junk 8y ago
    Gits adoption was driven by github, which won by making public repos free & private repos cost. If bitbucket had that business model instead of the inverse we’d all think of git as that weird bad hg that Linus forces the Linux devs to use. Git is a classic example of other factors than the software driving use.
    - paulsutter 8y ago
      Great then you should be able to do even better, right? Seriously give it a try
      - pjmlp 8y ago
        First we need to power up to Linus skill level, then we can apply the same community influence spells. Git would be dead on the water if it wasn't for being written by Linus and a requirement to interact with Linux development.
  - weberc2 8y ago
    I get the general thrust, but this argument can be used for any incumbent. `git` is popular because _github_ works. Had github's founders stumbled upon Mercurial first, we would all be in a moderately better place. But yes, at the end of the day, Git Is Good Enough (TM).
  - munificent 8y ago
    > Git isn’t ideal, but it is right. It’s right because it’s solving source code control for a huge percentage of software projects. Your statement is only true to the degree that it's a tautology: Git's popularity demonstrates that it's right and the definition of "right" is "popular". But if you want to use "right" to mean anything else, maybe to say something about it's technical merits independent of sociological factors like the network effect, first-mover advantage, high-profile early adopter, etc. then your sentence doesn't add any information. Personally, I think Git's user experience is an unremitting shitshow, the kind of disaster that makes one reconsider Hanlon's Razor. The technical capabilities buried under that UX are pretty nice, though you could probably discard 1/3 of them without impacting any noticeable fraction of users. The performance is excellent and it's very easy for developers to underrate how much that effects user satisfaction. And it had the good fortune to win on almost all of the sociological factors that largely determine product success.
TheDong 8y ago
This rings as a wrong interpretation of history. When git became successful, there were scant few other options with a comparable feature-set regardless of speed. Its distributed nature, ability to easily merge and rebase sets of changes, etc, were all wonderful solutions to real problems. I'm unconvinced that its success was because it solved fewer problems than the state of the art, but rather that it solved more. This is a stark contrast to vgo which is intentionally solving fewer problems than other modern dependency management tools. In addition, git must be performant enough to handle a git repo (namely the linux kernel, its original usecase). Beyond that, I think there's no evidence it intentionally cut features or complexity to be faster. In the case of vgo, it cuts additional user-facing features in order to be faster, but there's 0 evidence that the speed matters, that there are any go projects in the world that cannot be solved quickly enough with an approximation of a sat solver.
- emmelaich 8y ago
  (from memory) there was arch (larch,arx,) and monotone and others. They were glacially slow and difficult to use. But they had very roughly the feature set; in particular the distributed nature.
- enqk 8y ago
  Darcs was one of the well-known examples that could be brandished
- zaphar 8y ago
  Mercurial was pretty close to contemporaneus. And when git was first launched it was extremely bare bones and even more incredibly hard to use than it is now. Darcs, Monotone, and Arch were slower and I think predated git. Darcs in particular blew the doors off of git as far as ease of use given the problem domain. Git won almost entirely due to two factors. 1. The linux kernel used it so that brought some prestige. 2. Github made git hosting easy and free for a lot of people and had the cultural cachet to drive adoption. Git has a very solid underpinning. But it's user interface and lack of guard rails has always made it painful. People endure the pain because if they don't they won't be able to use the tool that their industry has chosen. But some of us wish a different choice had been made in the dvcs arena.
coldtea 8y ago
>On the other hand, git became successful by being fast In a totally different domain with involves working diffs for and managing gigabytes of source code....
littlestymaar 8y ago
You compare vgo to git but I think your comparison is backward, in regard of not solving “hard theoretical problems” git is more like current package manager. They don't care about the hypothetical NP-hardness of the problem. Vgo is an attempt to work-around this hard theoretical problem that doesn't even matter in practice.
zellyn 8y ago
That's the same hand. Unless I'm misunderstanding, pcwalton said that solving the hard theoretical problem doesn't even rate on his list.

by enqk 8y ago

lobster_johnson 8y ago

git may have become successful, but that doesn't mean it's right. I'd argue that most developers still don't really understand git. I know seasoned, senior developers who struggle when git gets into an unfamiliar state, or who are completely mystified as to how it actually works. And don't forget that git spent years improving its initially horrific UI to make it easier and more palatable to people who aren't kernel developers. If you compare git to rival tools such as Mercurial and Fossil or even Darcs, it's pretty evident that git didn't really win on technical merit, user friendliness or indeed hardly any other metric. It was fast, and it had the dubious advantage of being better than a lot of crappy alternatives at the time, and of being the product of a famous developer. But if technical merit was how we chose software, we might all be using Mercurial today. It's quite possible we'd be better off, too. git's punting of "certain of the hard theoretical problems" lead to major shortcomings in its design. For example, git does not track branching histories. Once you merge your changes back into a branch and delete the origin branch, the path that your commits took are lost. Another example: Since git's data model works entirely on repository snapshots (there are no "patches" or logical operations, only snapshots), it doesn't know about file renames. Some commands, like log and diff, do understand how to detect renames (but not out of the box!), but it's fundamentally a fuzzy-matching operation that can only work perfectly if you separate your rename commits from modification commits, which is rarely feasible. Don't get me wrong, git has overall been a force for good, but I think it's a pretty terrible example in this particular case. In fact, I'm not sure I can think of many cases where the "worse is better" philosophy was ultimately a good idea. In every instance that comes to mind (MySQL, MongoDB, PHP), the fast-and-loose attitude ultimately came back to hurt everyone, and years were spent paying for those mistakes, plugging one hole at a time. The original decision by the Go team to build package management into the language ("go get") was made without really understanding the problem, and this decision has been haunting us pretty much since day one, with developers having to chase unofficial package management tools of the week in order to get their work done. I really want it to be done right, even if takes a bit longer. It's a problem worth solving well.

paulsutter 8y ago
Git isn’t ideal, but it is right. It’s right because it’s solving source code control for a huge percentage of software projects. Something better could be even more right, and adoption would be the measure. > git may have become successful, but that doesn't mean it's right.
- kasey_junk 8y ago
  Gits adoption was driven by github, which won by making public repos free & private repos cost. If bitbucket had that business model instead of the inverse we’d all think of git as that weird bad hg that Linus forces the Linux devs to use. Git is a classic example of other factors than the software driving use.
  - paulsutter 8y ago
    Great then you should be able to do even better, right? Seriously give it a try
    - pjmlp 8y ago
      First we need to power up to Linus skill level, then we can apply the same community influence spells. Git would be dead on the water if it wasn't for being written by Linus and a requirement to interact with Linux development.
- weberc2 8y ago
  I get the general thrust, but this argument can be used for any incumbent. `git` is popular because _github_ works. Had github's founders stumbled upon Mercurial first, we would all be in a moderately better place. But yes, at the end of the day, Git Is Good Enough (TM).
- munificent 8y ago
  > Git isn’t ideal, but it is right. It’s right because it’s solving source code control for a huge percentage of software projects. Your statement is only true to the degree that it's a tautology: Git's popularity demonstrates that it's right and the definition of "right" is "popular". But if you want to use "right" to mean anything else, maybe to say something about it's technical merits independent of sociological factors like the network effect, first-mover advantage, high-profile early adopter, etc. then your sentence doesn't add any information. Personally, I think Git's user experience is an unremitting shitshow, the kind of disaster that makes one reconsider Hanlon's Razor. The technical capabilities buried under that UX are pretty nice, though you could probably discard 1/3 of them without impacting any noticeable fraction of users. The performance is excellent and it's very easy for developers to underrate how much that effects user satisfaction. And it had the good fortune to win on almost all of the sociological factors that largely determine product success.

TheDong 8y ago

This rings as a wrong interpretation of history. When git became successful, there were scant few other options with a comparable feature-set regardless of speed. Its distributed nature, ability to easily merge and rebase sets of changes, etc, were all wonderful solutions to real problems. I'm unconvinced that its success was because it solved fewer problems than the state of the art, but rather that it solved more. This is a stark contrast to vgo which is intentionally solving fewer problems than other modern dependency management tools. In addition, git must be performant enough to handle a git repo (namely the linux kernel, its original usecase). Beyond that, I think there's no evidence it intentionally cut features or complexity to be faster. In the case of vgo, it cuts additional user-facing features in order to be faster, but there's 0 evidence that the speed matters, that there are any go projects in the world that cannot be solved quickly enough with an approximation of a sat solver.

emmelaich 8y ago
(from memory) there was arch (larch,arx,) and monotone and others. They were glacially slow and difficult to use. But they had very roughly the feature set; in particular the distributed nature.
enqk 8y ago
Darcs was one of the well-known examples that could be brandished
zaphar 8y ago
Mercurial was pretty close to contemporaneus. And when git was first launched it was extremely bare bones and even more incredibly hard to use than it is now. Darcs, Monotone, and Arch were slower and I think predated git. Darcs in particular blew the doors off of git as far as ease of use given the problem domain. Git won almost entirely due to two factors. 1. The linux kernel used it so that brought some prestige. 2. Github made git hosting easy and free for a lot of people and had the cultural cachet to drive adoption. Git has a very solid underpinning. But it's user interface and lack of guard rails has always made it painful. People endure the pain because if they don't they won't be able to use the tool that their industry has chosen. But some of us wish a different choice had been made in the dvcs arena.

coldtea 8y ago

>On the other hand, git became successful by being fast In a totally different domain with involves working diffs for and managing gigabytes of source code....

littlestymaar 8y ago

You compare vgo to git but I think your comparison is backward, in regard of not solving “hard theoretical problems” git is more like current package manager. They don't care about the hypothetical NP-hardness of the problem. Vgo is an attempt to work-around this hard theoretical problem that doesn't even matter in practice.

zellyn 8y ago

That's the same hand. Unless I'm misunderstanding, pcwalton said that solving the hard theoretical problem doesn't even rate on his list.