Hacker News Reader

Comment by tiffanyh | Hacker News Reader

Is there a historical reason why git is needlessly complex?

Seeing this cheat sheet really brings it to life.

Yes. Because git was created by Linus Torvalds specifically to enable and advance Linux kernel development.

The fact it has become so widly adopted is a "happy accident" (or misery). Github I think has been widely credited with making git so common place ("free git hosting") but I don't think git is the "ideal" revision control system for many projects.

Because it was made for Linus for Linus/Linux, this is why the terminology and sometimes workflow is backwards from every other "normal" version control system. A "Pull Request" (PR) is named that because for Linux development Linus/maintainers would PULL changes into Linux kernel tree. In almost every other version control system it's called a Merge Request which logically makes MUCH more sense because you are merging a change (where ever it came from) into a tree.

Git was (still?) the only open-source distributed version control system that could handle enormous code bases with good speed which means it gained a lot of inertia at big companies as well.

I vastly prefer and use Mercurial for personal projects but if you have tried to use Hg on huge code bases (I've tried on Android AOSP) it really chokes. Mercurial got the "user interface" and command-set right and has some nifty features (being able to launch a web server on the fly to get a tree view of your changes) but being written in Python, performance and scalability aren't ideal.

> Mercurial got the "user interface" and command-set right and has some nifty features (being able to launch a web server on the fly to get a tree view of your changes) but being written in Python, performance and scalability aren't ideal.

I used to think Mercurial had a better UI but I changed my mind after taking the time to understand Git. Mercurial does have nifty features but Git's way of working isn't hard or especially counterintuitive. You must learn the terminology to properly understand it, but after that it's smooth sailing. Git actually has fewer moving parts than Mercurial, as there are less extraneous features. Instead of 3 or more categories of "branch-like" graph structures like Mercurial, you get branches as refs in Git. Every named leaf in the commit graph is a branch or a tag, and those have simple properties. There are surely git plugins to add more metadata but you don't really need that.

Git too has a web interface by default: https://git-scm.com/docs/gitweb Of course there are many Github-like solutions specifically catered to hosting repos and entire project workflows with Git too.

You must learn the terminology to properly understand it, but after that it's smooth sailing

This promise never held to me. I know the terminology and “how”, but it never got clear in my mind how to express day to day things which aren’t clone/add/commit/push. It’s just bad unmemorable ui that is both cumbersome to use and reason about.

I do have trouble remembering things but not like this with any other tool. For example, with ffmpeg and magick I could make them work without a manual. With git I can only damage things irrepairably.

Lol if you can remember how to use ImageMagick and Ffmpeg but not Git, I don't get it. Those programs do have very different argument passing styles than Git, but Git uses the same style as most every other unix/linux program. If you use it and know what you're doing, you should not be able to lose any work.

My advice to get over the hump you're on is to commit more often, check the status more often (`git diff [--staged]` and `git status`), and make sure you're branching or tagging enough to not lose commits. Then work on how to edit commits with `git rebase -i`. You can use rebase and cherry-pick to eliminate any unwanted commits or branches easily (notwithstanding conflicts, which are another critical thing to learn). If you feel like you messed up, you can almost always `git reset --hard` to the last commit you were on. If you forgot which commit you were on, there's the reflog. Generally, to be good at Git you have to take a few hours to learn it. It differs from the other programs you mentioned because there are different problems you can encounter at various points while using Git, whereas those other ones just succeed or fail and don't usually fail in unrecoverable ways (you just run them again until you're satisfied with the output). You can iterate on modifications to your commit history with Git but that is trickier and riskier.

There are many excellent Git tutorials online that explain everything an ordinary user needs, including rebases and the reflog. I think Github has one. Maybe that's what you need to figure it out, in addition to practice of course.

What ffmpeg and magick have in common that git doesn’t is (relatively) intuitive and straightforward arguments. They have lots of arguments, but they are otherwise simple and consistent. If I remember an idea, it always works the same and looks the same.

In git there’s always “foo”, “bar --frob” or “baz :QUUX -j” in a set of logically related operations, and neither of keywords make sense. Also every generation of git had its own ui ways, so it’s very hard to learn if it’s e.g. some reset/checkout incantation or just restore that you wanted, because when you refer to google, it never knows it’s not 2015 anymore. Some humans can’t learn inconsistent badly named things, I’m one of them. I can remember, but to actually understand I’d have to understand Linuses mind’s inner machinery, which is alien to me.

Idk which common Git commands you think are so incomprehensible or unstable between versions. Structure-wise, there's a combination of positional and non-positional arguments, but that's not uncommon on Linux. I haven't seen a major change in the way the Git UI works for the basics in the past decade, that I can recall. Of course Googling an answer to a problem can lead you off the beaten path, but I think that if you get an idea of what looks appropriate you won't be taken in by hairbrained approaches.

I think most of what you need is actually on this cheat sheet, so maybe all you needed was a reference.

> you won't be taken in by hairbrained approaches.

Hare-brained. (Hares are not supposed to be very smart animals.)

Looking at subj cheatsheet, I immediately see `git add .` described as adding ALL untracked files and unstaged changes. But deleted files will not be included, unless you pass -A / --all. But wait, that's just my memories, since git now does include removed files, according to my tests today and https://git-scm.com/docs/git-add#Documentation/git-add.txt--.... It's hard to tell if that changed in the past decade or not, cause the manual never mentions neither a version not that -A is default now in a section corresponding to -A. I still have -A in my bash aliases and it was 2017 when I finally got frustrated enough to create them.

And this complexity was literally from the first trivial thing I checked, I wasn't looking for it for hours to gaslight anyone here. Git is nice and fast as a core program, but its ui, documentation, compat and informational ecosystem are just poor.

What do you mean, "deleted files" -- removed from the git staging area with "git rm", or actually deleted on the file-system level? (I don't think it ever added the latter, did it?)

Yeah, I'd heard good things about the Mercurial UI but bounced off when "how to branch" turned up https://stevelosh.com/blog/2009/08/a-guide-to-branching-in-m... with not one but three radically different answers. Seemed somehow unfinished to me.

I wouldn't say that these features are unfinished. They're just "extra" features that don't really add anything to the experience. People who like Mercurial rationalize and say that this gives you more options, of course. I think you can't really delete named branches in Mercurial, but don't hold me to that. The one that corresponds to Git branches is bookmarks, and of course bookmarks are the last thing you ever learn about when you are picking up Mercurial.

It is kinda nice to not be able to accidentally lose a branch even if you're a low-skill Mercurial user, and that is the main selling point for most people. On the other hand, low-skill Git users lose stuff often. It's actually really hard to lose committed stuff in Git because of the reflog, but the low-skill users never heard of that and you can really have a hard time explaining it to them. The other big complaint is about `git reset` and its various incarnations. People really don't take the time to understand what it does with its various options, and when they delete their changes accidentally they blame the tool.

It might also help understanding, when talking about the history of git, to keep in mind that it came to be out of the urgent need for a tool to replace (then still proprietary) BitKeeper. I wouldn't say that bk is as hard to grok as git, but it's certainly complex as well. I wonder if some of git's idiosyncrasies are a result of intentionally avoiding a look&feel equivalent to bk lest that would alienate Mr. McVoy.

I can't say I was front and center to everything happening, but I always thought it was strange that Linux used Bitkeeper which is very not open-source. So many battles have been fought around Linux and GPL that this seemed a bit hypocrtical.

Of course things were run afoul when Tridge started reverse engineering the bk protocol/datastructure but frankly the need to switch away from bk was a bit self-inflicted from what I could tell.

> So many battles have been fought around Linux and GPL that this seemed a bit hypocrtical.

Throwing all in one bucket necessarily leads to confusion. Sure, there were and are FOSS zealots and Linux zealots and there is an overlap. Linus Torvalds himself however is a very practically minded guy who clearly expressed that he would use proprietary software if it would suit his needs better. He got a lot of heat for that stance, as some Linux kernel developers happen to be more ideologically pure. No need to warm that battle up.

(oh, BTW, BitKeeper is FOSS since about 2016)

There's a C version of hg, and more recently a rust version. I can't say how much faster they are though

I don't think those other implementations were ever finished.

Some of the complexity comes from the fact that in earlier versions it was reasonably expensive to add new subcommands. As a result more functionality got added to existing subcommands like git checkout. This made the UX more confusing.

In newer versions of git the cost of adding new subcommands is reduced and they've started adding more specific commands like git switch.

The addition of `switch` and `restore` has probably reduced my daily cursing-at-git rate by half.

Why was that?

I think most of the time you’d be ok just knowing a couple of git commands (log, add, commit, pull, push, ..?). And of course there’s also GUI tools.

I don’t think git is that complex for most workflows to be honest. But there is a lot of power that is available if the need arises.

It's not needlessly complex. The workflow it was created to support is inordinately complex, and the target market for that is highly technical, so its complexity was not the issue. Kernel developers needed to communicate to other kernel developers in a decentralized manner, and needed to work on top of each other. How do you work on a project where there are 15,000 people writing code? Git was created for this purpose.

It's as complex as it needs to be to support the workflows it was designed to be. A dumber tool would be easy to create, but then it would not be able to support more complex workflows like linux kernel development. So it's not needlessly complex, though it is more complex than it needs to be for simple use cases.

For those needing a less complicated frontend, there's a large number of them to make it easier to interact with git. For people that aren't full-time software developers, I don't recommend using git directly. However for those that are, it's worth taking the time to understand the underlying concepts so git becomes something you understand because once you do, it's quite elegant for what it does. I'm not going to gatekeep being a software developer on whether or not you know git, but if figuring out for yourself how such a fundamental system works doesn't give you a release of dopamine, this might not be your kind of thing. Which is totally fine. There are tons of things that are and aren't my thing.

I recommend https://learngitbranching.js.org for learning how to navigate around git.

but of course, https://xkcd.com/1597/ applies as well.

After learning Jujutsu, I realized this is really wrong. The underlying data structures and operations are great, and they serve their purposes really well (such as supporting 10k+ people collaborating like you mentioned). They are what makes git great. The git command line interface is a needlessly complex abstraction on top of them that tries to encourage certain behaviors, but does a really bad job at it.

100% agree.

The fact there are 5 different ways to do the same thing is BAD, not good. Have one well defined, documented clear way to solve a problem.

There are 3 different ways I could get to the store, I could walk or drive or bicycle. There are also 3 different paths I can take. I could go down road A, sidestreet B, or alleyway C. I know you'd rather one big button to press that just says "do it" on it, but in order to perform complex actions on complex objects, there are going to be multiple ways to accomplish the same thing.

But what if one of the ways to the store is dangerous once in a while but usually safe and always just as fast as the other 2 ways to the store.. Laziness has nothing to with the posters question. There is nothing wrong with Git , I just don't agree with the comparison.

But if the dangerous route takes only 15 minutes, and the safe ones take an hour, why shouldn't I, being fully aware of the risks, have the option to take it when I want to?

I don't know where I called anyone lazy.

I'll have to dig into https://github.com/martinvonz/jj hadn't heard of it before. Either way, there's an underlying data structure with operations to be performed on, the interface to it is shit, and learning the underlying data structure makes it all make sense.

So where is the totally refactored/revamped CLI that applies Occam's Razor ?

Jujutsu

https://github.com/martinvonz/jj

I see that (in principle at least) it can be a simple UI for an existing git repo but then it gets kind of complicated again discussing how that works.

I can tell you how to do a bunch of things with Jujutsu without looking it up: how to rebase a tree of branches given a common ancestor, how to do a 3+ way merge, how to split the changes in a commit into multiple commits, how to duplicate a branch, how to find all of the commits that haven't made it into the default branch...

I can't tell you how to do a single one of these things in git without looking it up. My years of experience with git is around a decade I think. My experience with Jujutsu adds up to about 3 months.

Sure, there are things that I would still have to look up how to do with Jujutsu; I don't know all of its features. I think the operations I know how to do with Jujutsu off the top of my head are strictly a superset of the operations I know how to do with git though.

There's a common(?) use case for git/jujutsu that I can't find a simple answer to:

I clone a repo. I make some changes to my copy. But then I want to keep my copy up to date with the original repo by stirring in all the updates that have been made lately to the original repo.

Seems like it oughta be simple, but git makes it mysterious. Will jujutsu make this possible using only simple, sensible CLI commands ? And conflicts will be nicely stored away for near-term cleanup ?

Inquiring minds want to know.

jj fetch # get the most recent changes from the remote

jj rebase -b @ -d branch@remote # rebase the branch of the current working commit onto the newly fetched commits.

Note that the way to do this with git is almost identical, but maybe not as obvious. In git I think this can be done with a single command though: git pull --rebase.

If this is not the state you want your repo to be in and I misunderstood, I'm still pretty confident I could get a repo in the state you want using Jujutsu quite easily :)

Edit: though also the git way to do this would kind of force you to deal with cleaning up conflicts immediately, whereas with Jujutsu you can put off conflicts indefinitely.

"Needlessly" can be in the eye of the beholder, but given that Linus basically put it together to solve the problem he was trying to solve without consulting a UX team or building a product for the ages, I would be willing to place my probability bar pretty high on the design tilting towards "One person's best idea right now" over "Best design theoretically possible."

That having been said, the team is really good at engines so the software is quite good at doing what it's supposed to do.

WCan you give at least a few examples of complex operations that only arise at the scale of thousands of people?

Because good UI design requires a different skill and takes extra effort to achieve, so it's most often just ignored

Git is not complex. Its UI is!

Git is very simple. It is built on just four concepts: blobs, trees, commits, refs.

Because Linus had more clout in the SE industry than anyone else and said “SVN bad” and nobody wanted to do enough research to disprove him so here we are.

Merging in Subversion is a complete disaster. The Subversion people kind of acknowledge this and they have a plan and their plan sucks, too. It is incredible how stupid these people are.

So for example, let's go back to one of the things where I think the designers of Subversion were complete morons. Strong opinions. That's me, right? There's a few of them in the room today, I suspect. You're stupid. (Crowd laughs)

Nobody is interest in branching. Branches are completely useless unless you merge them.

https://sandeep.ramgolam.com/blog/linus-torvalds-talks-about...

Reply on news.ycombinator.com