3 ms·

A part of Git's complexity is due to the fact that it was originally meant to be just the plumbing. It was expected that more user-friendly porcelain would be w

by goku12 3y ago

A part of Git's complexity is due to the fact that it was originally meant to be just the plumbing. It was expected that more user-friendly porcelain would be written on top of the git data model. Perhaps that is still the best bet at having a simple and consistent UI. Jujutsu and Got (game of trees) are possible examples.

dayjaby 3y ago
That's a bold statement. Any proof or article where Linus states that?
- goku12 3y ago
  If you mean the plumbing part, I recalled it from memory. I don't have anything from Linus to back this up. But have a look at this from the Pro-Git book [1]: > But because Git was initially a toolkit for a version control system rather than a full user-friendly VCS, it has a number of subcommands that do low-level work and were designed to be chained together UNIX-style or called from scripts. Note that its author (schacon) is also the author of the article and is replying in this discussion thread. I also remember reading somewhere that this design was the reason for the complexity in the porcelain. Will update if I find a reference. [1] https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Po...
  - schacon 3y ago
    Boy, I can't find this either (but also, the kernel mailing list is _really_ difficult to search). I really remember Linus saying something like "it's not a real SCM, but maybe someone could build one on top of it someday" or something like that, but I cannot figure out how to find that. You _can_ see, though, that in his first README, he refers to what he's building as not a "real SCM": https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23ca2e25604af290#diff-2b7814d3fca2e99e56c51b6ff2aa313ea6e9da6424804240aa8ad891fdfe0900R89-R93 https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23...
    - schacon 3y ago
      So, I found the git-pasky project in the _very_ early days (like a couple days after Linus's first git commits) and iirc, it was an attempt to build an SCM-like thing over the plumbing that Linus was working on: https://marc.info/?l=linux-kernel&m=111315057710062&w=2 https://marc.info/?l=linux-kernel&m=111315057710062&w=2
    - goku12 3y ago
      Here is what I found based on your lead ("real SCM", from 17 Apr 2005): > That was really what I always personally saw "git" as, just the plumbing beneath the surface. For example, something like arch, which is based on "patches and tar-balls" (I think darcs is similar in that respect), could use git as a _hell_ of a better "history of tar-balls". [1]: https://lore.kernel.org/git/Pine.LNX.4.58.0504170916080.7211@ppc970.osdl.org/ https://lore.kernel.org/git/Pine.LNX.4.58.0504170916080.7211...
      - schacon 3y ago
        Nice, yes, I think this is what I was remembering. Good find!
- oasisaimlessly 3y ago
  Well, the existence of and story behind cogito [1] should be decent proof. [1]: https://en.m.wikipedia.org/wiki/Cogito_(software) https://en.m.wikipedia.org/wiki/Cogito_(software)
- sodapopcan 3y ago
  I wouldn't say it's very bold at all. I don't have any links but if you've been using git for the past decade, you would have heard something along these lines. "A toolkit for building VCS's" is one thing I remember reading. There was little in the way of polish when it came to porcelain commands when people started using it. I think there are still many people who don't use it who still think it's still this way.
iraqmtpizza 3y ago
>originally meant to just the plumbing this describes all of unix. as soon as scripts were allowed to use commands, those commands could never be changed. lest we have a nerd riot on our hands
- goku12 3y ago
  Creating an alternative UI is rather uncontroversial. The plumbing doesn't need replacement. Jujutsu for example, seems to be popular.
  - iraqmtpizza 3y ago
    Ha, replacement? You can't even get them to fix bugs. If you fix a bug in a unix command you'll break every script in existence and bring the world down. It's idiotic. The user's a file! The internet's a file! Keyboard is a file! What are checkboxes? This is a volunteer project! You can't expect us to include UI in the OS! We'll just bikeshed forever so sorry, write your own, lol.
    - withinboredom 3y ago
      Getting a bug fixed in rsync, pulled down to LTS Ubuntu took a single email. I’m not sure what you are going on about.
      - iraqmtpizza 3y ago
        Congratulations. You just broke userspace.
        beeboobaa 3y ago
        You clearly have no idea what you are chattering about. The saying "Don't break userspace" is for the kernel. It has nothing to do with userspace programs potentially affecting other userspace programs.
bluetomcat 3y ago
It's a collection of hacky tools for manipulating a DAG of objects, identified by a SHA-1 hash. If you look at it this way, you wouldn't expect any consistency in the CLI interface.
- zukzuk 3y ago
  I don’t think this is a fair characterization. The reason git is confusing is that its underlying model doesn’t resemble our intuitive conceptual model of how it ought to work. This was classic Torvalds — zero hand holding. But he gets away with it because the way git works is brilliantly appropriate for what it’s intended to do (if you just ignore the part where, you know, mere mortal humans need to use it sometimes). I ended up writing my masters thesis a decade ago about the version control wars, and I (somewhat grudgingly) came away in awe at Torvalds’ technical and conceptual clarity on this.
  - masklinn 3y ago
    > The reason git is confusing is that its underlying model doesn’t resemble our intuitive conceptual model of how it ought to work. No. The reason git is confusing is that the high-level commands have very little thought put into them, they are indeed “a collection of hacky tools to manage a DAG of objects”. That the underlying model shines through so much is a consequence of the porcelain being half-assed and not designed. The porcelain started as a bunch of scripts to automate common tasks. The creators and users of those scripts knew exactly what they wanted done, they just wanted it done more conveniently. Thus the porcelain was developed and grouped in terms of the low level operations it facilitated.
  - rafacm 3y ago
    Is your Master’s Thesis available online?
- hyperhopper 3y ago
  Not true at all. https://stevelosh.com/blog/2013/04/git-koans/ https://stevelosh.com/blog/2013/04/git-koans/

by goku12 3y ago

dayjaby 3y ago

That's a bold statement. Any proof or article where Linus states that?

goku12 3y ago
If you mean the plumbing part, I recalled it from memory. I don't have anything from Linus to back this up. But have a look at this from the Pro-Git book [1]: > But because Git was initially a toolkit for a version control system rather than a full user-friendly VCS, it has a number of subcommands that do low-level work and were designed to be chained together UNIX-style or called from scripts. Note that its author (schacon) is also the author of the article and is replying in this discussion thread. I also remember reading somewhere that this design was the reason for the complexity in the porcelain. Will update if I find a reference. [1] https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Po...
- schacon 3y ago
  Boy, I can't find this either (but also, the kernel mailing list is _really_ difficult to search). I really remember Linus saying something like "it's not a real SCM, but maybe someone could build one on top of it someday" or something like that, but I cannot figure out how to find that. You _can_ see, though, that in his first README, he refers to what he's building as not a "real SCM": https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23ca2e25604af290#diff-2b7814d3fca2e99e56c51b6ff2aa313ea6e9da6424804240aa8ad891fdfe0900R89-R93 https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23...
  - schacon 3y ago
    So, I found the git-pasky project in the _very_ early days (like a couple days after Linus's first git commits) and iirc, it was an attempt to build an SCM-like thing over the plumbing that Linus was working on: https://marc.info/?l=linux-kernel&m=111315057710062&w=2 https://marc.info/?l=linux-kernel&m=111315057710062&w=2
  - goku12 3y ago
    Here is what I found based on your lead ("real SCM", from 17 Apr 2005): > That was really what I always personally saw "git" as, just the plumbing beneath the surface. For example, something like arch, which is based on "patches and tar-balls" (I think darcs is similar in that respect), could use git as a _hell_ of a better "history of tar-balls". [1]: https://lore.kernel.org/git/Pine.LNX.4.58.0504170916080.7211@ppc970.osdl.org/ https://lore.kernel.org/git/Pine.LNX.4.58.0504170916080.7211...
    - schacon 3y ago
      Nice, yes, I think this is what I was remembering. Good find!
oasisaimlessly 3y ago
Well, the existence of and story behind cogito [1] should be decent proof. [1]: https://en.m.wikipedia.org/wiki/Cogito_(software) https://en.m.wikipedia.org/wiki/Cogito_(software)
sodapopcan 3y ago
I wouldn't say it's very bold at all. I don't have any links but if you've been using git for the past decade, you would have heard something along these lines. "A toolkit for building VCS's" is one thing I remember reading. There was little in the way of polish when it came to porcelain commands when people started using it. I think there are still many people who don't use it who still think it's still this way.

iraqmtpizza 3y ago

>originally meant to just the plumbing this describes all of unix. as soon as scripts were allowed to use commands, those commands could never be changed. lest we have a nerd riot on our hands

goku12 3y ago
Creating an alternative UI is rather uncontroversial. The plumbing doesn't need replacement. Jujutsu for example, seems to be popular.
- iraqmtpizza 3y ago
  Ha, replacement? You can't even get them to fix bugs. If you fix a bug in a unix command you'll break every script in existence and bring the world down. It's idiotic. The user's a file! The internet's a file! Keyboard is a file! What are checkboxes? This is a volunteer project! You can't expect us to include UI in the OS! We'll just bikeshed forever so sorry, write your own, lol.
  - withinboredom 3y ago
    Getting a bug fixed in rsync, pulled down to LTS Ubuntu took a single email. I’m not sure what you are going on about.
    - iraqmtpizza 3y ago
      Congratulations. You just broke userspace.
      - beeboobaa 3y ago
        You clearly have no idea what you are chattering about. The saying "Don't break userspace" is for the kernel. It has nothing to do with userspace programs potentially affecting other userspace programs.

bluetomcat 3y ago

It's a collection of hacky tools for manipulating a DAG of objects, identified by a SHA-1 hash. If you look at it this way, you wouldn't expect any consistency in the CLI interface.

zukzuk 3y ago
I don’t think this is a fair characterization. The reason git is confusing is that its underlying model doesn’t resemble our intuitive conceptual model of how it ought to work. This was classic Torvalds — zero hand holding. But he gets away with it because the way git works is brilliantly appropriate for what it’s intended to do (if you just ignore the part where, you know, mere mortal humans need to use it sometimes). I ended up writing my masters thesis a decade ago about the version control wars, and I (somewhat grudgingly) came away in awe at Torvalds’ technical and conceptual clarity on this.
- masklinn 3y ago
  > The reason git is confusing is that its underlying model doesn’t resemble our intuitive conceptual model of how it ought to work. No. The reason git is confusing is that the high-level commands have very little thought put into them, they are indeed “a collection of hacky tools to manage a DAG of objects”. That the underlying model shines through so much is a consequence of the porcelain being half-assed and not designed. The porcelain started as a bunch of scripts to automate common tasks. The creators and users of those scripts knew exactly what they wanted done, they just wanted it done more conveniently. Thus the porcelain was developed and grouped in terms of the low level operations it facilitated.
- rafacm 3y ago
  Is your Master’s Thesis available online?
hyperhopper 3y ago
Not true at all. https://stevelosh.com/blog/2013/04/git-koans/ https://stevelosh.com/blog/2013/04/git-koans/