34 ms·

Linus was moving off of BitKeeper, which obviously was some of the inspiration for git - but the underlying model is nothing alike. Git's data model is much sim

by beagle3 10y ago

Linus was moving off of BitKeeper, which obviously was some of the inspiration for git - but the underlying model is nothing alike. Git's data model is much simpler than CVS, RCS, Subversion, BitKeeper and basically anything else that existed at the time, and it was also much faster. The command line interface doesn't reflect this properly, but it's the underlying model that counts. Git is nothing like a reimplementation of BitKeeper - the closest inspiration and model is actaually Monotone, which had the same basic concepts but was slow and clunky. IIRC, Torvalds credited monotone/Hoare for using merkle trees (and other things)

tomjakubowski 10y ago
> The command line interface doesn't reflect this properly, but it's the underlying model that counts. Could you explain why, for a tool meant to be used by humans, the underlying model (which I agree is very elegant) counts more than the user interface?
- gcp 10y ago
  the underlying model (which I agree is very elegant) counts more than the user interface? It does not. But git exposes this all the time, so committed git users feel that's a good thing, because understanding it makes helps them to make sense of some of the worst parts of the UX.
  - FatalBaboon 10y ago
    Git is the reference implementation of a protocol, and much like HTTP, you must learn it the hard way if you intend to be a professional in the domain. The mistake is to believe there is a U<I|X> in the first place. It does not, however, stop you from using one of the many graphical tools, that are fine for simple usage and will all eventually fall short. You could use a GUI to make complex HTTP routes, through proxies and DNS records via drag&drop, and then one day you'll have some weird DNSSEC error that the maintainer does not care about, and you will have to explain that to whoever is losing money. Acknowledging a problem is not as trivial as it was first thought is critical in our line of work in my opinion.
    - gcp 10y ago
      Git is the reference implementation of a protocol In reality this "reference implementation" is the sole interface 99% of the users use, so the lack of UX is an issue. There are other tools that do it better and right, so insisting that there's any redeeming qualities to git here is being blind to the obvious. There's actual academic research describing git's problems here, for crying out loud.
      - glandium 10y ago
        > There's actual academic research describing git's problems here, for crying out loud. And interestingly, all the academic research talks about is the high level UI. Not the underlying data model. > In reality this "reference implementation" is the sole interface 99% of the users use /That/ is the mystery to me. I don't see a reason why a better UX around the same underlying data model, talking to the same server (and thus interacting natively with e.g. github) hasn't picked up. Heck, one could implement mercurial's UX on top of the git data model. In fact, that even has been prototyped. I can't find the repository anymore, but iirc it was somewhere on bitbucket.
        beagle3 10y ago
        There are at least five such front ends (easygit comes to mind) and extensions (like legit from Kenneth Reitz). But none is popular, and I suspect the reason is that, despite all the complaining, Git's default UI is not actually that bad in day to day use.
- Arnt 10y ago
  A source code version control system has to be in control of the source code. The model clearly is important to whether git is in reliable control of the source we entrust to it. Function matters more than anything else... and exactly what "function" means and encompasses can be discussed, but it's difficult to define function such as to exclude git's model from git's function.
- hueving 10y ago
  Every time you reference a commit by its hash, you are interacting with the model. Rebasing, merges, etc are all based on this.
- raimue 10y ago
  Git was originally not meant to be used by humans, as the man page of git(1) still reflects today: git - the stupid content tracker The interface that humans should use would have been cogito, but after some time there was no interest anymore in this and it was discontinued. http://git.or.cz/cogito/ http://git.or.cz/cogito/
- hellofunk 10y ago
  In any software program, how you model the data tends to be at the root of all else in the program. If you screw that up and make it complex unnecessarily, you will have an inferior program. You can put a bad UI on a good model, but you cannot expect much stability from any UI on a bad model. It's just like the movies. You can make a bad movie from a good script, but a bad script never, ever made a good movie.
huhtenberg 10y ago
Furthermore, Linus wasn't just moving off of BitKeeper, he had to and quickly. Tridge (another kernel dev) reversed BK protocol and repo structure, as trivial as they were. BK people got understandably upset about this, in part because they were providing BK to the Linux Kernel Project for free. So Tridge's little stunt basically killed any and all goodwill between BK and LKP and Linus needed a replacement. All alternatives had issues and everyone just kept going in circles, bitching and moaning. So in a true programmers way Linus sat down and wrote what he wanted. The end.
- michaelmrose 10y ago
  The first mistake was for a free software project to require a proprietary one to participate in development. Bitkeeper's sole claim of ownership moral or legal was to the bitkeeper software which nobody violated. What Tridge did was come up with another way for the owners of the relevant data to access their own information something wholly reasonable and justified. What you dismiss as a stunt proved in a stroke how much of a mistake the relationship with Bitkeeper was. This is approximately like sony records telling you that you can't take your cd and put it in a Samsung stereo and you defending sony except no reasonable person supposes that creators of material objects aquire moral rights to control the use thereof.
  - geezerjay 10y ago
    > The first mistake was for a free software project to require a proprietary one to participate in development. This isn't true at all. Anyone could download the source code, tweak it, and submit patches. You can even use your own version control system to track your changes. The project managers may have used bitkeeper, but to everyone else the only thing that bitkeeper provided was, at best, convenience.
    - gcp 10y ago
      It's detrimental to the openness of a project if the maintainers and core contributors have other, better tooling than the rest of the world.
hyperpallium 10y ago
Linus's initial commit of git makes it easier to see its essential simplicity: http://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23ca2e25604af290 http://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23c... HN discussion: https://news.ycombinator.com/item?id=8650483 https://news.ycombinator.com/item?id=8650483 Content-addressing (ie hashes) enables decentralization (hashes are the same whereever you are) and integrity (changing content will change the hash). (Perhaps inspired by Tridge, who did rsync which uses hashes to test for content changes?) It's incredibly fast because commits are almost as simple as copying, and because Linus knows how to C. Linus left out some features, like renames (which bitkeeper has), so this simple idea would be enough. Some people rave about the index/cache, though it's separable from the core idea.
- beagle3 10y ago
  The inspiration was Monotone, not rsync: https://en.wikipedia.org/wiki/Monotone_(software)#Monotone_as_Git_inspiration https://en.wikipedia.org/wiki/Monotone_(software)#Monotone_a...

by beagle3 10y ago

tomjakubowski 10y ago

> The command line interface doesn't reflect this properly, but it's the underlying model that counts. Could you explain why, for a tool meant to be used by humans, the underlying model (which I agree is very elegant) counts more than the user interface?

gcp 10y ago
the underlying model (which I agree is very elegant) counts more than the user interface? It does not. But git exposes this all the time, so committed git users feel that's a good thing, because understanding it makes helps them to make sense of some of the worst parts of the UX.
- FatalBaboon 10y ago
  Git is the reference implementation of a protocol, and much like HTTP, you must learn it the hard way if you intend to be a professional in the domain. The mistake is to believe there is a U<I|X> in the first place. It does not, however, stop you from using one of the many graphical tools, that are fine for simple usage and will all eventually fall short. You could use a GUI to make complex HTTP routes, through proxies and DNS records via drag&drop, and then one day you'll have some weird DNSSEC error that the maintainer does not care about, and you will have to explain that to whoever is losing money. Acknowledging a problem is not as trivial as it was first thought is critical in our line of work in my opinion.
  - gcp 10y ago
    Git is the reference implementation of a protocol In reality this "reference implementation" is the sole interface 99% of the users use, so the lack of UX is an issue. There are other tools that do it better and right, so insisting that there's any redeeming qualities to git here is being blind to the obvious. There's actual academic research describing git's problems here, for crying out loud.
    - glandium 10y ago
      > There's actual academic research describing git's problems here, for crying out loud. And interestingly, all the academic research talks about is the high level UI. Not the underlying data model. > In reality this "reference implementation" is the sole interface 99% of the users use /That/ is the mystery to me. I don't see a reason why a better UX around the same underlying data model, talking to the same server (and thus interacting natively with e.g. github) hasn't picked up. Heck, one could implement mercurial's UX on top of the git data model. In fact, that even has been prototyped. I can't find the repository anymore, but iirc it was somewhere on bitbucket.
      - beagle3 10y ago
        There are at least five such front ends (easygit comes to mind) and extensions (like legit from Kenneth Reitz). But none is popular, and I suspect the reason is that, despite all the complaining, Git's default UI is not actually that bad in day to day use.
Arnt 10y ago
A source code version control system has to be in control of the source code. The model clearly is important to whether git is in reliable control of the source we entrust to it. Function matters more than anything else... and exactly what "function" means and encompasses can be discussed, but it's difficult to define function such as to exclude git's model from git's function.
hueving 10y ago
Every time you reference a commit by its hash, you are interacting with the model. Rebasing, merges, etc are all based on this.
raimue 10y ago
Git was originally not meant to be used by humans, as the man page of git(1) still reflects today: git - the stupid content tracker The interface that humans should use would have been cogito, but after some time there was no interest anymore in this and it was discontinued. http://git.or.cz/cogito/ http://git.or.cz/cogito/
hellofunk 10y ago
In any software program, how you model the data tends to be at the root of all else in the program. If you screw that up and make it complex unnecessarily, you will have an inferior program. You can put a bad UI on a good model, but you cannot expect much stability from any UI on a bad model. It's just like the movies. You can make a bad movie from a good script, but a bad script never, ever made a good movie.

huhtenberg 10y ago

Furthermore, Linus wasn't just moving off of BitKeeper, he had to and quickly. Tridge (another kernel dev) reversed BK protocol and repo structure, as trivial as they were. BK people got understandably upset about this, in part because they were providing BK to the Linux Kernel Project for free. So Tridge's little stunt basically killed any and all goodwill between BK and LKP and Linus needed a replacement. All alternatives had issues and everyone just kept going in circles, bitching and moaning. So in a true programmers way Linus sat down and wrote what he wanted. The end.

michaelmrose 10y ago
The first mistake was for a free software project to require a proprietary one to participate in development. Bitkeeper's sole claim of ownership moral or legal was to the bitkeeper software which nobody violated. What Tridge did was come up with another way for the owners of the relevant data to access their own information something wholly reasonable and justified. What you dismiss as a stunt proved in a stroke how much of a mistake the relationship with Bitkeeper was. This is approximately like sony records telling you that you can't take your cd and put it in a Samsung stereo and you defending sony except no reasonable person supposes that creators of material objects aquire moral rights to control the use thereof.
- geezerjay 10y ago
  > The first mistake was for a free software project to require a proprietary one to participate in development. This isn't true at all. Anyone could download the source code, tweak it, and submit patches. You can even use your own version control system to track your changes. The project managers may have used bitkeeper, but to everyone else the only thing that bitkeeper provided was, at best, convenience.
  - gcp 10y ago
    It's detrimental to the openness of a project if the maintainers and core contributors have other, better tooling than the rest of the world.

hyperpallium 10y ago

Linus's initial commit of git makes it easier to see its essential simplicity: http://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23ca2e25604af290 http://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23c... HN discussion: https://news.ycombinator.com/item?id=8650483 https://news.ycombinator.com/item?id=8650483 Content-addressing (ie hashes) enables decentralization (hashes are the same whereever you are) and integrity (changing content will change the hash). (Perhaps inspired by Tridge, who did rsync which uses hashes to test for content changes?) It's incredibly fast because commits are almost as simple as copying, and because Linus knows how to C. Linus left out some features, like renames (which bitkeeper has), so this simple idea would be enough. Some people rave about the index/cache, though it's separable from the core idea.

beagle3 10y ago
The inspiration was Monotone, not rsync: https://en.wikipedia.org/wiki/Monotone_(software)#Monotone_as_Git_inspiration https://en.wikipedia.org/wiki/Monotone_(software)#Monotone_a...