Hacker News Reader

Comment by patatino | Hacker News Reader

I do not want to learn git tricks. I just wanna use it as simple as possible. Just let me push my code and be done with git and keep on working.

Kudos to all who love git, for me, it's just a tool I have to use.

View on HN

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.

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.

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/

I understand your sentiment but git is really not all that hard. And knowing a few things that go beyond bog-standard checkout/commit/push, especially history-rewriting activities, will greatly improve quality of commit-history - which might not be of much use for you but might help other engineers working on your project to make easier sense of what's going on.

And on another note, git is probably one of the longer-lasting constants in our industry. Technologies develop and change all the time, but for git, it looks like it's here to stay for a while, and it's probably one of the tools we interact with most in day-to-day dev-work. Might be worth having a bit of a look at :)

I'd argue that CVS outlasted git by at least a couple of decades...

"Outlasted", in the past tense? We won't know that until git is dead, will we?

There is detail inherent in the problem and some not. I tend to think we underestimate the inherent problems.

So I'm happy for the 'complexity' of git.

I do not want to learn programming. I just wanna use the computer as simple as possible. Let me just tell it what to do and be done with it.

Kudos to all who love programming, for me, it's just a tool I have to use.

Isn’t that where most interest starts? A computer really is a tool. I know for me, it was an unfortunate discovery at the very start of my interest in computing that to do the things I wanted I had to deal with all these tedious bits of programming.

Even today I’d like to skip most of the underlying tedious bits although I understand knowledge and willingness to deal with much of those underlying tedious bits are what keep money flowing into my account regularly. That’s about the only saving grace of it. There are so many ideas I’d love to explore but the unfortunate fact is there’s a lot of work to develop or even glue together what one needs to test out, not to mention associated infrastructure costs these days. Even useful prototypes take quite an endeavor.

My feeling is that the git interface is a leaky abstraction. I also don't want to learn git tricks, but unfortunately I learned more about it than I wanted to.

> do not want to learn git tricks. I just wanna use it as simple as possible.

Simplicity is in the eye of the beholder. A single trick can save you a whole lot of work. Take for example interactive rebate which allows you to update your local branches to merge and reorder local commits. If you had to do everything by hand you would certainly have to work a lot more.

Honestly, get outside of commit and pull and my brain feels dread like regular expressions.

Hopefully the incantation is on the Cheat Sheet and I don't make it worse.

I had the same experience for a long time and then I took a bit of time to have a deeper look behind the curtain and I have to say, once you grasp the data-model of git itself (a branch is a pointer to a commit, a commit is a pointer with metadata to a tree, a tree is...), many of the commands start to make sense all of a sudden, or at the very least "stop looking dangerous".

As it's one of those rare tools that's probably meant to stay for quite some time and we interact with quite frequently, it was time well spent for me, and it turns out it's really not as hard as the scary-looking commands imply.

This generic statements can be said about basically any technology (MS MFC anybody? (L)DAP? IBM Websphere studio J2EE abominations?) if you are smart enough / have enough time to dig around. It doesn't help discussion at all (and plenty of folks complain about git all the time), since one can't avoid being branded as lazy/stupid if its not grokking this uber important yet trivial tool like me (TM).

But then there is Mercurial, used it decade and a half ago and it contained literally everything good about distributed model I could ever wish for, with maybe 50% of Git's complexity. Yet cargo-culting gonna cargo-cult, if Linus uses it so must we since we are not subpar and the rest be damned.

Yes sure its the tool to stay, and eventually can be learned well. But its design is far, very far from the most important software design principle (KISS).

> But its design is far, very far from the most important software design principle (KISS)

My suggestion was more to look at the underlying data-model, which really isn't that much harder to grasp than what your average undergrad datastructure course teaches. Git really does solve a rather complex problem in a quite elegant way - it just so happens that the packaging around it (the cli) is indeed a bit more controversial.

I can only speak for myself but once I started to look at git less like "a tool" and rather from a perspective of datastructure/algorithms etc. (which are inherently agnostic to how they're implemented), it started to make sense to me rather quick (a matter of hours actually, which is nothing compared to the countless of hours I've already wasted trying to find the right cheat-sheet-incantation before).

As long as you remember that the reflog exists (and it hasn’t run gc, but usually you immediately know when you’ve messed up), you’ll be fine. It’s exceedingly hard to break your repo beyond repair without trying to do so.

It's unfortunate that the weight of ecosystem and tooling (and the 800 point Microsoft-owned GitHub gorilla) has effectively locked the profession into using git. I don't hate it, I'm just keenly aware that a better approach is possible.

I wish someone with deep pockets would hook the pijul team up with the money and talent they need to make pijul a full-featured alternative with first-class hosting tools. The way it models change is principled and based on solid theory, and I'm convinced that a markedly better tool than git could be built on that foundation.

Why even use git then? `scp code server:code` does what you need.

This isn't a rhetorical question.

Because all the organizations that pay me to write code host their code centrally on GitHub

> GitHub

But then it's GitHub you need to know, not git.[1] And doesn't that have a point-and-clicky Web interface, like any "Upload files here!" Web site?[2]

[1]: Seems you're being fooled, by organisations that also believe it, that git is GitHub and/or vice versa.)

[2]:Sorry, I've had an account there since about forever, but hardly ever (never?) used it.

This is a complete non-sequitur. Whether I use a point-and-click interface or a CLI has nothing to do with the fact that I have to use a git-based workflow and can't just copy files to the server as a deployment.

Totally agree. However, then coworkers who don't understand even the simple git commands mess up their branches (somehow), and... then my git tricks save the day (unfortunately).

I agree, what more is needed than push and diff and branching, sometimes reset and rebase

same

I don't totally disagree. I love Git and I find all these things very cool, but I know it's overhead a lot of people don't want. The post is on the blog of the new GUI that I'm trying to build to make the cool things that Git can do much faster and more straightforward, so maybe check it out if the CLI isn't your favorite thing.

Beyond a junior engineer, I’d expect an engineer to know more than the basics if they’ve been using git for their entire career so far.

Git is the power saw for software engineers. You don’t want someone who can’t keep all their fingers and toes anywhere near your code.

Not knowing git, when you’ve been interacting with it for years, is a red flag for me. I’m not expecting people to know the difference between rebase and rebase --onto, but they should at least know about the reflog and how to unfuck themselves.

Reply on news.ycombinator.com