Hacker News new | ask | show | jobs
by wokwokwok 1758 days ago
hm. vexing.

I feel like this is mostly accurate, to my knowledge, but reading this:

> I do not claim that this way of looking at Git represents absolute “facts” in any hard and fast or literal sense. But I contend that if you conceive of Git in the way that I’m going to suggest, if you substitute these conceptions of Git for any misconceptions you might have now, you’ll be a much happier and more fluid Git user.

…vexes me.

“Think of git like bowl of peanuts and marshmallows” and other pointless, wrong, metaphors about how git works are a dime a dozen.

Yet, here is someone who is clearly quite familiar with git, and they go to pains to point out they are simplifying and may not be correct in their explanations.

Its good to be humble, but ffs, git is too frigging complicated if the best you can get is a “probably wrong simplified mental model of how it works so you can be a bit more productive with it”.

I dont care;

- a simple meaningless metaphor that lets you be more productive? OK.

- a accurate description of how things actually work? OK.

…but pick one.

What I do not want is a possibly wrong complicated explanation of how git maybe works.

3 comments

This article presents an accurate picture of how things work at a high conceptual level. It glosses over certain details, because git is very complex. For example, git has, if I recall correctly, 4 staging areas, of which represent different sources when it comes to a merge conflict. However, this detail can mostly be ignored because it’s not relevant to the high level conceptual ideas this article is trying to present.

I would argue most things in technology are complex, and mental models are intentional ways to take something complex and turn it into something more simple. This article does not create meaningless metaphors.

> However, this detail can mostly be ignored because it’s not relevant to the high level conceptual ideas this article is trying to present.

Personally speaking, I find knowing and distinguishing among the 4 indexes to be essential to understanding git. Not including and really exploring that detail gives people an incorrect mental model of what's happening.

Marvelous, if the metaphors of the article helped you, but I empathize with the upstream poster's frustration. I believe that the content of the article is not medicine for the malaise it describes.

The official documentation for `git add` refers to "the index". I'm not seeing any reference to multiple indexes. I've been using git for years, and I've never heard of it. I read a book about it. But parts of it are definitely still mysterious to me. Anyway, where can I find any evidence of these 4 indexes?
Sorry, category error. I was using index to refer to the category of which index is a member. Maybe areas is better. These are the 4 ... things...:

working directory - this is the project directory in the OS file structure

index - a.k.a the staging area

repository - in the .git directory

stash - a kind of scratch pad or clipboard for the developer

Understanding these different areas and how and why to move data into each is essential to understanding git

While you are correct, this is not what I was referring to.

To be exactly clear, there are actually 4 staging areas within what you referenced as the index. This is indeed a detail most people do not worry about.

You see this in the comments here too. Everyone has to add a disclaimer to every statement about how (they think) git works: “As far as I know”, etc.
And it's not even necessary -- the git data model is simple. It's simple enough that you can generate valid commits in about a page lines of python, with no libraries. The rest is just packing files for efficiency, and finding the difference between hash lists for syncing and pulling.

The command line interface to git is insanely complicated, confusing, and unnecessarily difficult to use, but this isn't a result of the git data model. It's definitely possible, to give a complete and accurate description of the data model, even using examples from `git cat-file` to walk through the commit history by hand.

I've also got a simple demo that generates a complete repo with a commit. You can manipulate the resulting repo from git. There are 65 non-comment lines of code.

Here it is: https://orib.dev/ugit.py