11–20 of 94 posts
When I realized it's just a DAG and you're just manipulating a graph and pointers. Then it just became a matter of mapping git CLI commands to how they manipulate the graph.
Just goes to show the power of understanding the fundamentals of CS :-)
Although I do use git from the cli (or magit) primarily, this knowledge has helped me pick-up front end tools intuitively and have helped others when I've never used their preferred tool. All of this doesn't seem possible unless you've put in the effort learning what's going on behind the scenes. That is to say, git itself it neither user friendly nor intuitive it must be learned.
Knowing mercurial (hg) beforehand did slow my learning progress a bit with all the false-friends. You may find it easier to learn if you don't have to re-learn some naming.
Are you using it from the command line? I feel that helps a lot. Get a good log alias[1] and get hacking. I almost exclusively use the official CLI, with the exception of git-gui for committing and rolling back patches (lines / hunks). (I find it's easier than `add -p` and that CTRL+J is a good time saver.)
1: As an example, https://github.com/aib/dotfiles/blob/master/.gitconfig#L29
What's important to understand about git is that it allows time travel, and time travel enables changing history, and changing history is a really bad idea. Do not ever change the history without knowing what you're doing. In git, this means mostly rebasing and other stuff that messes with existing commits. Messing with existing commits can be fine as long as you're messing with the only existing version of that comm…
When I realized it's just a DAG and you're just manipulating a graph and pointers. Then it just became a matter of mapping git CLI commands to how they manipulate the graph.
Now I just have to learn what a DAG is
Edit: yeah, it's acyclic not acrylic :).
I have not grokked git — it hasn't been necessary to. Understanding some of the basics, knowing enough of the commands to run, and figuring out which StackOverflow answer applies to my current situation is good enough. If I have to spend too much time knowing its internals and delving into its philosophies, then it is not a useful tool that lets me get on with my tasks.
But I don't think I should need to fully understand its internals for it to be "grokkable", an elegant thing could still be grokkable regardless.
It's possible though that the tasks: diffing, branching, merging, rebasing, tagging, etc., are too elusive for "elegance", ha ha.
I might add though that simple diffing, branching, merging I do more or less grok. Perhaps if git had stopped there, like my understanding did, I would feel more comfortable with it ... imposed limitations be damned. I suppose in fact I only use git in this limited capacity anyway. It's only when someone else on the team does something clever (or I screw something up)....
This took me from "add/commit/push, and pull" to being able to do rebases: https://learngitbranching.js.org/