The purpose of this article is to present a simple way of looking at what Git really is and what it really does. 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. When posed with a puzzle as to what happened, what will happen, what you should do in order to make a certain thing happen, the answer might suddenly be obvious, where previously it wasn’t.
Picturing Git: Conceptions and Misconceptions
21–30 of 105 posts
Re: Picturing Git: Conceptions and Misconceptions
#22Ugh. 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…
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 tree, the index, the stash, the repo ADG, the local remote repo ADG, the remote repo ADG. Of course the branch labels are further state, and working with the commits directly is discouraged. Oh and files can be either tracked or not, and they can either be ignored or no. And one isn't a subset of the other. And that also interacts with the various state transitions.
Re: Picturing Git: Conceptions and Misconceptions
#23Ugh. 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.
The way I tried to understand Git at first was like Subversion. Horrible. I almost deleted everything my team worked on for weeks.
Then I read "git inside out" [1] (not to be confused by "git from the bottom up" which I think is not as good), had a "aha!" moment, my view changed and everything became clear and easy. Transformation from graph to graph is something I do every day, so why not in Git?
[1] https://www.slideshare.net/MichaelNadel/git-inside-out-57904...
Re: Picturing Git: Conceptions and Misconceptions
#24Ugh. 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…
Reminds me of: Bad programmers worry about the code. Good programmers worry about data structures and their relationships. -Linus Torvalds Anyway, it's not for everyone to get to understand git this way, I guess. Some people will just react "just tell me how to do X in git!"
Sometimes you just want your tool to get out of your way and get the job done, instead of deeply understanding it. No shame in that. There are limited hours in the day and sometimes other things are more important.
Re: Picturing Git: Conceptions and Misconceptions
#25Ugh. 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.
So what's your conclusion from this failure? That everyone else is stupid? You're a bad teacher? Or it's not actually simple and the above explanation includes a ton of implicit understanding of the subtle interactions of the various moving parts?
Re: Picturing Git: Conceptions and Misconceptions
#26Earlier quoted context omitted.
2. Tags are named, mutable pointers to commits. 3. Branches are named, mutable pointers to commits, that you can "ride". While you "ride" a branch it keeps moving to always point to your latest commit. 4. HEAD is an implicit branch that you "ride" at all times.
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.
As far as I know, tags don't have an identity beyond their name. The CLI tries to steer you away from replacing tags (by naming the option --force rather than, e.g., --modify), but that doesn't make them immutable.
Re: Picturing Git: Conceptions and Misconceptions
#27Ugh. 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…
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 to multiple commands. I guess it's easier for me to think in graphs.
Re: Picturing Git: Conceptions and Misconceptions
#28Ugh. 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…
More directed acyclic graph (DAG), which I suppose is still a type of graph. That said I'm not sure if "graph" is conceptually better than "tree with cross connections". People that struggle with git may not have a good enough grasp on the differences between these structures that insisting on using the "proper" names is immediately helpful.
Re: Picturing Git: Conceptions and Misconceptions
#29Ugh. 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…
[deleted]
Re: Picturing Git: Conceptions and Misconceptions
#30I 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 repo or create one from an existing remote repo
gl status - show status of the repo
gl track - start tracking changes to files
gl untrack - stop tracking changes to files
gl diff - show changes to files
gl commit - record changes in the local repo
gl checkout - checkout committed versions of files
gl history - show commit history
gl branch - list, create, edit or delete branches
gl switch - switch branches
gl tag - list, create, or delete tags
gl merge - merge the divergent changes of one branch onto another
gl fuse - fuse the divergent changes of one branch onto another
gl resolve - mark files with conflicts as resolved
gl publish - publish commits upstream
gl remote - list, create, edit or delete remotes
Working on a feature and want to look at the main branch, but not ready to commit the changes yet? Well just switch to the main branch, then switch back and pick up where you started. No need to know about an additional data structure called the stash.
Unfortunately this did not pick up enough steam. And because a lot of tools expose concepts from gits broken interface you have to learn the git interface anyway...