Hacker News Reader

Comment by goku12 | Hacker News Reader

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.

View on HN

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.

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.

> 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.

Is your Master’s Thesis available online?

Not true at all.

https://stevelosh.com/blog/2013/04/git-koans/

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

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-Po...

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/e83c5163316f89bfbde7d9ab23...

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

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...

Nice, yes, I think this is what I was remembering. Good find!

Well, the existence of and story behind cogito [1] should be decent proof.

[1]: https://en.m.wikipedia.org/wiki/Cogito_(software)

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.

>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

Creating an alternative UI is rather uncontroversial. The plumbing doesn't need replacement. Jujutsu for example, seems to be popular.

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.

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.

Congratulations. You just broke userspace.

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.

I found and fixed a bug in Debian’s vixie-cron where if the system time clock changed without restarting crond, it wouldn’t modify its runs until the next DST event.

This was well-received without complaint or concern for breaking people’s [insane] workflows that may be relying on that behavior.

Note that Jujutsu is not exactly a frontend for Git (it is only loosely coupled to Git) -- Git is one of at least two backends for Jujutsu.

This describes all of programming. They are called dependencies and they tend to be versioned. Breaking changes affect literally every aspect of software development. Software that isn’t maintained will no longer function at some point in the future.

> as soon as scripts were allowed to use commands, those commands could never be changed

That's not a script thing, that's an API surface thing, and even then only applies to backwards-incompatible changes. You can change the arguments to git or chmod just as easily as printf() or fork()

As I said here already, the difference is that scripts are interpreted, rarely if ever check what version they're running on before they attempt to do something, and the authors of the scripts have been explicitly encouraged to memorize a heapload of letter permutations and throw a thermonuclear systemd-sized fit if something changes.

None of this is inherent to APIs.

Reply on news.ycombinator.com