Picturing Git: Conceptions and Misconceptions • Hacker News Board

Re: Picturing Git: Conceptions and Misconceptions

#31

Post by Certhas » Thu, Sep 02, 2021, 4:38 PM UTC

bironran wrote: post #27

Certhas wrote: post #22

Earlier quoted context omitted.

Sorry, but what? Specifically: what about your writing justifies the assertion that git is simple? Git is a horrible convoluted set of commands to make a lot of different data structures [1] interact. And if you do it wrong you can get into very weird states. This is not simple in any meaningful sense of the word! Heck, "a monoid in the category of endofunctors" is simpler. [1] From the top of my head: The working tr…

Any system with a limited amount of concepts is simple. Emergent properties are easy to predict and explore. Physics of "perfect friction-less sphere in vacuum" is so easy to understand we teach in grade schools and toddlers grasp it by instinct. I can't (yet) reason about monoids easily. But I can reason about Git, even if I can't figure out the single command to change the state the way I want it and have to resort…

But it's not a limited amount of concepts. One sphere in a vacuum is easy, three spheres is hard. Git has half a dozen subtle interacting data structures. But because people have built up a lot of experience working with them (and don't coach beginners and non-programmers) they shout "it's just an ADG, so simple!" and pretend like everything is fine...

Re: Picturing Git: Conceptions and Misconceptions

#32

Post by rudedogg » Thu, Sep 02, 2021, 4:43 PM UTC

wokwokwok wrote: post #4

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

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.

Re: Picturing Git: Conceptions and Misconceptions

#33

Post by jldugger » Thu, Sep 02, 2021, 4:51 PM UTC

> Picturing Git: Conceptions and Misconceptions

Based on the title, I was expecting a more in-depth study of user misconceptions about git, similar to the famous CogSci paper "Two Theories of Home Heat Control." Except with like, diagrams.

And now I want someone to make that happen.

Re: Picturing Git: Conceptions and Misconceptions

#34

Post by hanche » Thu, Sep 02, 2021, 4:54 PM UTC

globular-toast wrote: post #16

bironran wrote: post #9

Ugh. So many concepts. So many things to remember. Why? Git is simple. SIMPLE. But only, IMO, if you go bottom-up and not top-down. There are only 6 critical concepts in Git and each is simple enough to be described in a single sentence. 1. Commits are immutable blobs that have one or more parents. Graphs, not trees. Anyone who uses trees for git commits misses the whole point and makes their (and their collaborators…

This is the way I understand git. For me it's dead simple. I've tried to teach others over the years. Not a single person has got it so far.

That reminds me about the old joke about monads: At the moment you finally understand them, you lose the ability to explain them.

Seriously, I too find the basic concepts of git quite simple. But whenever I want to do anything slightly out of the ordinary, I find myself wasting a lot of time searching the docs. In fact, I find the naming of commands and their options almost the opposite of intuitive, given my understanding of the basic model.

Re: Picturing Git: Conceptions and Misconceptions

#35

Post by rendall » Thu, Sep 02, 2021, 5:11 PM UTC

Quenty wrote: post #11

wokwokwok wrote: post #4

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

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 prese…

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

Re: Picturing Git: Conceptions and Misconceptions

#36

Post by rendall » Thu, Sep 02, 2021, 5:19 PM UTC

I avoid using words like "simple" when writing about technical topics. "It is simple!" is not inclusive language and, love git or hate git, it is not inherently simple. It takes effort to understand, and experience to avoid its pitfalls.

Re: Picturing Git: Conceptions and Misconceptions

#37

Post by shepherdjerred » Thu, Sep 02, 2021, 5:26 PM UTC

bironran wrote: post #9

Ugh. So many concepts. So many things to remember. Why? Git is simple. SIMPLE. But only, IMO, if you go bottom-up and not top-down. There are only 6 critical concepts in Git and each is simple enough to be described in a single sentence. 1. Commits are immutable blobs that have one or more parents. Graphs, not trees. Anyone who uses trees for git commits misses the whole point and makes their (and their collaborators…

Git is definitely not simple. It's simple if you have a solid understanding of data structures (trees, graphs), and know the concept of a pointer. Not everyone has that background. The concepts are learnable, but the commands have complex behavior that often require reference to use properly. The commands aren't simple by any measure because of all of the edge cases that exist.

Re: Picturing Git: Conceptions and Misconceptions

#38

Post by zauguin » Thu, Sep 02, 2021, 5:29 PM UTC

Certhas wrote: post #30

karaterobot wrote: post #2

I read most of this long article, and I found it useful, but: It's unsurprising that people's mental model of git is incorrect. Git is not something people study at a conceptual level, it's something they learn recipes for in order to work on some project. Recipes like "how do I save all this work I just did" and "oh shit, everything is hosed, please give me a magic spell I can paste into my terminal to fix it". I do…

I think it's the other way around. The fact that git does not provide a clean analogous way to intuitively interact with it just demonstrates that the git interface is horribly broken. This is not essential complexity, it's just bad design that stuck. Take a look at https://gitless.com/ If you just look at a summary of the commands, you will have an accurate mental model of what's going on: gl init - create an empty…

Having used `gitless` a while ago as my main interface I strongly disagree. Having a distinction between my working tree and things I'm actually considering to commit is a luxury you only really start to miss when it's gone. IMO gitless makes it way too easy commit too much. Also it's "feature" of keeping uncommitted changes local to the branch is just weird. If I want to make a branch specific change, I create a commit. This has the big advantage that it actually forces the user to add a message what the change is about, so if something else comes up I know what was going on when coming back to it later. It's not like this has to be a formal commit message, after all the commit can be dropped again later. Otherwise you end up being surprised by old experiments when switching to branches you haven't used in a while. If I just switch branches then the most likely reason for that is that I want to move the changes.

Re: Picturing Git: Conceptions and Misconceptions

#39

Post by mercutio2 » Thu, Sep 02, 2021, 5:31 PM UTC

kubanczyk wrote: post #20

bironran wrote: post #17

Earlier quoted context omitted.

afaik, the commit a tag points to is immutable unless you delete and recreate (and then nothing is immutable really). re "ride" - that's exactly what I'm trying to avoid. It's an additional concept that isn't needed to understand Git. You need to understand the model. The "ride" is an emergent property of the model and commands that you eventually understand, but not a core part.

Without the concept of "riding", terms "tag" and "branch" would become exact synonyms. In that case you can just remove point 2 (consider it just a syntactic sugar) and thus simplify your list. If a tag has any attempt at immutability at the data structure level, I know nothing of it.

It's all about how other clients treat branches and tags.

Once you've pushed a tag, no other clients will be willing to update their definition of that tag unless the users on those other devices force the issue.

So operationally, "tags are immutable once pushed" is a pretty reasonable way to look at things.

Remotely pushed branches of course also won't allow you to do anything but append without forcing on remote clients, so mutable and immutable isn't quite right, here.

So I guess I agree with your original contention, branches are mutable-and-you-can-ride where ride means "the remote client's porcelain will be happy with append mutations".

Re: Picturing Git: Conceptions and Misconceptions

#40

Post by BossingAround » Thu, Sep 02, 2021, 5:35 PM UTC

jimbob45 wrote: post #5

darekkay wrote: post #3

That's the blog post I always wanted to write. So many people spend little to no time to actually learn Git, because "it's just a tool to help you doing your "real" work" (=coding) . Or because "Git is too difficult/confusing/broken". Or because "I don't need anything except commit/push/pull". I find those arguments somewhat true, but I still feel that people are missing out when they don't learn a tool they use dail…

It is just a tool to help you do your real work and famously gets in the way. You use SVN and it covers 99% of use cases much more simply than Git manages.

I've never used SVN, but I assume that because git uniformly won as the VCS tool, it suits most people better than SVN..?