reading online discussions about git is always really funny because 50% of the people are like "i don't understand git" and the other 50% say “no you just have to understand git is a directed acyclic graph where branches are pointers to commits" and nobody learns anything

(the discussions we've been having on here have been going MUCH better than this and I'm very grateful for that)

@b0rk Tbh I’ve been the second guy too many times. Started substituting “flowing river” for acyclic graph because analogies explain abstractions better than more abstractions.

@vees me too, i'm only very very slowly learning how to explain git now. it's really hard.

git discussion bingo card

@b0rk rofl I'm 100% subversion was better

I'm also wrong but that won't stop me

@leif i'm not here to judge

@b0rk I think the biggest stumbling block for new users is misunderstanding that patches are presentation not data model.

The data model you're working with is states/snapshots of the entire project tree and the "was derived from" relationships between them, along with human provided textual descriptions of how a state relates to the one(s) it was derived from.

Patches are visual representations of those relationships.

@dalias yea i've heard that point of view a million times but personally my experience is that repeatedly saying "no, commits are snapshots, they're not diffs” to people doesn't help much

@b0rk Is it "too technical" still, or something else? As an advocate for git I'd love to figure out how to explain it in a way more likely to click with folks.

@dalias I think the only answer I can give is that I'm working on writing a zine about git and you can buy it when it's done :)

@dalias i still haven't figured out how to talk about commits but I'm thinking about it a lot.

@dalias here's an example of an interesting discussion about how commits work i had with someone yesterday (though please don't try to explain commits is to them) https://mastodon.social/@t_i_m/111454953950715654#.

@b0rk I love the "hard to imagine it being so fast"... 🤦 Humans have become accustomed to the hideous slowness of contemporary web/cloud based world where it takes GitHub 100x as long to render one file as it takes git to process the entire Linux kernel history.

@dalias i'm a lot more sympathetic obviously, i do not personally find it trivial to reason though which things in git are slow and which things are fast and why. I think implying that people are dumb for being confused is a mistake.

@b0rk I must admit, I am taking deep joy in your experience of the git deep dive. Mainly because it validates my deep dive experience. ;-)

And hey, maybe--MAYBE--your zine will drive me to stop using RCS and CVS.

@mwl i mean if CVS works for you it works

@mwl the other day i was asking people about preferred text editors and 2 people told me entirely seriously that they prefer ed to vim because it's what they're used to

@b0rk

no you just have to understand git is a directed acyclic graph

As someone who has worked with directed acyclic graphs in the past, I now feel guilty for understanding that sentence 😅

@yuki2501 haha I am 100% the "you just have to understand git is a DAG" person in my heart, i've been doing a LOT of work to get myself out of that mindset and see it from a normal person's perspective. I just don't say that to people because I know it's not helpful.

It's really a challenge for me and I thought for years that I could never write about git because of it.

@b0rk I like how these answers are split between pragmatists and people that want to prove they're smarter than others in the discussion.

@heathborders honestly I 100% understand the “git is a directed acyclic graph” person, the only difference between me and them is that I know that saying that stuff is not helpful and just comes off as posturing so I keep my mouth shut.

It's been a big challenge for me to get out of that mindset.

@b0rk I just want to say that I like git. And I understand it.

I just don't know why I understand it, or how to explain it to other people.

@mullaney it's really hard, i've been working on it for months now and i still do not know how to explain what a commit is

@b0rk You have likely heard this one before, and forgive me if you have. But I like to think of it as a saved game in a text adventure game.

But instead of saving everything, you are only saving the precise moves you made since the last save. Left, right, look at object, take chest, etc.

So each commit is a set of changes or steps since the last time you saved.

A saved chess game might be a good analogy too, since chess moves can be represented in text form.

@mullaney yea I've heard a million different explanations and I don't like any of them, I wasn't asking for advice thanks :)

@b0rk do you have a suggestion of a good version of the “acyclic graph” explanation? Because (having been trained as a mathematician) I might be one of the few people for whom that explanation would be helpful, and I would love to understand got better

@cohomologyisFUN oh man great question! I don't know offhand but does it help if I say:

1. commits form a DAG because they contain one or more pointers to their parent commits (you can see the parent with `git cat-file -p COMMIT_ID`, the `parent:` in there defines the edges), the nodes are commits
2. a "history" is every node that's reachable from a given commit
3. branches are pointers to a commit (they're text files like `.git/refs/head/main` which contain a commit ID)

@cohomologyisFUN i think it’s honestly still pretty challenging even if you understand the basic graph stuff because the graph theory really isn’t complicated at all, the problem is there’s a lot of bad terminology you need to get used to that has nothing to do with math https://jvns.ca/blog/2023/11/01/confusing-git-terminology/

@b0rk and yet nobody said "lets' move to mercurial where things are sane and easy". what the hell...

@ghorwood don't worry i made a bingo card for you https://social.jvns.ca/@b0rk/111460966674032287#.

@b0rk @mwl Somebody should write a book about how to master ed. ;-)

@dhemery @mwl i gave a guest lecture recently in a class where i i used the ed book as a good example of how humor is important in technical writing

@dhemery @b0rk nobody is THAT daft

@NetHandle @b0rk

Think of a DAG as a tree. It has a root, it has nodes, and branches and leaves.

The only difference between a DAG and a tree is that you can join branches together, and then sprout even more branches after. You can join as many branches you want, and split them again as much as you want.

It CAN be used as a flow chart, but it can also be used to represent compressed dictionaries.

Biotech companies use DAGs to digitally store genomes for easy and efficient search of individual genes.

@yuki2501 @NetHandle obviously i personally do not think explaining DAGs to people is the right approach but can you leave me out of it if that's what you're going to do

@NetHandle @yuki2501 @b0rk It is (flowcharts are directed graphs) and isn't (not all flowcharts are acyclic). From C go back to A (where you were earlier) can exist in flowcharts but not in a DAG; this makes a DAG easier to reason about (like a river it may split and join but flows nominally downhill). However, a DAG also does not typically involve other aspects of flowcharts such as "if".

@NetHandle @yuki2501 @b0rk (sorry; mathematician. not only is it _definitely_ mumbo jumbo words slapped together, but every single one of them has a formal definition.)

@b0rk is Fossil (the version control system made by the team that made SQLite and that SQLite itself is developed in) just not popular enough to be mentioned? https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki

@22 i mean there's pijul darcs monotone jj bzr sapling perforce git-branchless i just did not feel like listing all of them

@dch haha to me gpg/pgp's only saving grace is that filippo says it's bad so I feel comfortable just permanently giving up and never learning it https://words.filippo.io/giving-up-on-long-term-pgp/

@b0rk You should have put "I always use git commit -m because I don't know how to exit vim" on there

@alex i'm actually so mad about that, like i love vim for myself but the way git drops people into it feels so hostile

@b0rk I am about to say something dumb:

I think everybody should do one of those "implement Git in your favorite language" tutorials before trying to use Git. Because then they'll have a Git client that has 90% of the functionality that everybody actually uses, due to... um... well.... Git being Git. The rest seems to fall into the above "I don't know what's going on, copy the files you changed into a temp directory, delete your local repo and re-clone it, copy them back, and file a new PR because we know it'll work that way" category.

@drwho yea i hear that a lot and I don't agree, I love implementing a toy version (cf https://implement-dns.wizardzines.com/) but it's just too much to ask of people, most people do not have time for that. For sure if you feel like doing that it can be a fun project though.

@b0rk I genuinely don't know how I would have learned as much git as I know if I hadn't worked in a heavy pairing + trunk-based development shop

Simple rebases have been a part of my workflow for years and that + occasionally running into a gnarly git state while pairing with someone know knows how to reflog turned out to be a decent way to teach most of the more mysterious stuff about git

@b0rk I'm finding your git work especially useful personally because my ability to *teach* git is relatively bad compared to my ability to *use* git which is awkward when I'm working with people who mostly have experience with "normal" feature branch workflows

@dalias @b0rk I kinda disagree here. I mean, yes, this is how git does it, but this really is an implementation detail, quite irrelevant for anyone wishing to use git as a version control tool (let's leave aside the argument whether git is a VCS or not).

@vriesk @b0rk It's *not* an implementation detail. It means the software is not aware of any structure to the changes you made. It also affects your expectations for how rebases, merges, etc. work, and that version identifiers (hashes, tags, etc.) semantically refer to a state not to the changes that led to that state.

@dalias @vriesk if you’re going to argue about this can you leave me out of it thanks

@b0rk I've used git for about a decade and I will never understand how it works.

@benpocalypse @b0rk I don't think I'll ever fully understand it either. But as long as I keep getting better at it, I like to think that's good.

Not sure I'll ever fully understand "rebase onto" though. (Rebase? Sure. But every time I try to understand onto, my head starts spinning.)

@ThatBlairGuy @benpocalypse @b0rk I just substitute the word “rebase” with “graft” in my mind and it removes my confusion.

@boxofsnoo @benpocalypse @b0rk In my case, it's not terminology. And even straight up "rebase" makes sense (I think of it as "Apply the commits from this other branch that the current one doesn't have").

But "rebase onto" somehow involves three different branches and I've just never been able to wrap my brain around it. (And I'm the guy a number of my co-workers come to when they have git questions.)

@benpocalypse @b0rk only a decade? I think I’ve been using git for almost 20 years and I still have no idea what I’m doing. At least now I manage to get through most days without having to wipe and reclone the repo

@ThatBlairGuy i feel the same way, i think rebase onto just solves problem that i don’t have

@ThatBlairGuy @benpocalypse @b0rk try https://www.cduan.com/technical/git/ it's the only git tutorial which ever worked for me.

@nat @b0rk I’ve been wanting to give a talk about how I think about git for a while now, since I’ve never really sat down and explained my backing mental model for working with it to anyone, only really just what commands to use when pairing/helping people with git.

@b0rk I want to add “Git is a blockchain” to it but I don’t want to take out any of them either 😭

@alatiera too real

@b0rk hello and welcome to my life lol

@ksylor haha it's so much

@b0rk I have said "you should just read pro git" so many times this year and I will never stop staying it

@b0rk I don’t know the “porcelain” reference and now I know I’m going to be googling that later. 😃

@b0rk I guess I should read Pro Git (which I'm guessing might be a book about git), since it's the only reference I didn't understand.

@oantolin I'm not the biggest fan of that book but a lot of people like it. I have referenced the internals section occasionally https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain

@philcrissman @b0rk Ugh, dang, checking off that box, I guess. 😬

https://social.kejadlen.dev/notice/AbbLX6ZeNp9NGzmjNg

Dang, @b0rk does not miss.

RE: https://social.jvns.ca/users/b0rk/statuses/111460966674032287

@alpha @b0rk It is nice feeling seen, isn’t it?

@alpha @b0rk Oh yeah that was brutal.

@b0rk thank you for your response. I am a fan of your work.

ETA: thanks for the blog post, too. That is super helpful!!

@b0rk BTW, since this conversation, I purchased and read your zine "Oh Shit, Git!" and found it very helpful. Thanks 😀👍

@cohomologyisFUN amazing! Katie did such a great job with that