4 ms·

> I believe that Git becomes understandable if we peel back the curtain and look at how Git stores your repository data. I agree, and like many, I have been sa

> I believe that Git becomes understandable if we peel back the curtain and look at how Git stores your repository data. I agree, and like many, I have been saying that for years (nay, for more than a decade): and that's exactly the problem! You don't need to understand how an internal combustion engine works to drive a car... You don't need to understand how your graphics card renders stuff to develop a web page... You don't need to know how a brushless motor works to use a drill... There is a pattern there, and it's the one that makes sense. I've read up on the internals of git a dozen times by now. But I only occasionally need to do something weird that makes me go back to it, so I usually forget the relevant bits. The trouble is that I've used a distributed VCS that did not ask me to understand internals and it had a sane UI, and good model (like tree-like commit history, so a top-level commit log would only have merges, but you could dive deeper into individual commits if you so pleased). It wasn't perfect, but it's hard for me to accept that we have gone with a subpar solution where every "tutorial" starts with how you need to understand the internals! But you also need to memorise them, dammit! Just like I keep forgetting the Emacs rectangle editing shortcuts since I seldom use them, I'll keep forgetting the specifics of git internals that I might need once every 12 months. And it's not me, it's _you_, git!

mdnahas 6y ago
Sadly, the bad part is git's user interface. It hides the pretty parts underneath. There is a concept of "the next commit" or, equivalently, "the pending commit". In the documentation, this gets called "indexed" or "cached" or "staged" --- three different names! And if you want to diff with it, you can't refer to it by name. You need to use an option, so it's "git diff --cached <other commit>. I know git's internals, mostly because it lets me navigate its bad user interface.
leni536 6y ago
Commits being snapshots is not git internal. It is the high level abstraction.
sergeykish 6y ago
But you have to know how ICE works to resolve issue. Oil pressure? Engine temperature? Leaking radiator? Gas pump? Dead battery? Wet spark plugs (on older models)? But there is more — air filter, oil filter, oil change, mechanical parts — these usually resolved by handling car to professionals, and they have to know how system works. You have to understand DOM to resolve web page issue. Understanding how graphic card works would help in resolving webgl issues.
- necovek 6y ago
  We are not talking about people implementing git the tool. We are talking about people using git as a tool (even though they share the common job title of a software engineer/developer). The OP leads in with how "git cherry-pick" and "git rebase" are hard to use and promises to clear it up with a deep dive. You know, how do I turn the wipers on my car? Or turn signals? > You have to understand DOM to resolve web page issue. Understanding how graphic card works would help in resolving webgl issues. As a developer working to build things with DOM, you have to understand the DOM APIs and model. You do not have to understand how DOM is _implemented_ in browsers today and how they achieve things you need when you call the APIs. Sure, there are gotchas that are useful to know ("this CSS selector takes O(n^2) time to match"), but they are the exception, not the rule. Similar holds for WebGL: you need to know the APIs and how to use them effectively. Sure, it's good to know where some of the gotchas are ("this might re-render the whole thing on-screen introducing flicker, here's the off-screen version"), but it's not a blocker. But, none of these require you to understand internal implementation details to effectively use the public APIs (which with git are CLI commands). This is not to say that understanding the nitty-gritty details of anything is a bad thing: it is a GREAT thing, and will probably empower you to do ever more intricate things (and it is usually a very rewarding exercise to learn more about a tool you use)! But that's different from having to know the internals to do the most basic of things (which I'd argue "cherry-pick" and "rebase" are).
  - sergeykish 6y ago
    With DOM, you have to know that it is tree. Or you'd be surprised that `append` changes parent. You have to understand reflow, you have to understand stacking, lots and lots of things. A lot of people use DOM without understanding, a lot of people use git without understanding. In both cases one requires some knowledge to resolve issue. And git is trivial, it stores snapshots, nothing hard there. It is interesting, but does not help with `cherry-pick` and `rebase`. The only hard thing about git is recovering — git reflog — easily avoided with backup branches `git branch foo`. Some kind of undo could be useful for beginners to avoid fear of screwing things up. Git has a different mindset from SVN — commits are cheap, branches are cheap, experiments produces new branches, cherry-pick them, rebase them, etc, etc, etc.
TeMPOraL 6y ago
There's a difference between implementation details and core abstractions you need to know to understand a device. That git stores data as an immutable DAG with a layer of pointers to attach human-readable names to things, that's not an implementation detail. That's a core abstraction. It's not like knowing the internals of an ICE, it's like knowing a car moves using wheels, that these wheels must touch the ground for the car to be controllable, and some of them must rotate to change the direction of movement. Knowing such "car internals" isn't necessary for you to be able to turn the key and get it to roll - but it is necessary for safe driving. People who didn't master these "car internals" are the ones who speed on wet ground, don't understand safe braking distance, or why their car skids.

mdnahas 6y ago

Sadly, the bad part is git's user interface. It hides the pretty parts underneath. There is a concept of "the next commit" or, equivalently, "the pending commit". In the documentation, this gets called "indexed" or "cached" or "staged" --- three different names! And if you want to diff with it, you can't refer to it by name. You need to use an option, so it's "git diff --cached <other commit>. I know git's internals, mostly because it lets me navigate its bad user interface.

leni536 6y ago

Commits being snapshots is not git internal. It is the high level abstraction.

sergeykish 6y ago

But you have to know how ICE works to resolve issue. Oil pressure? Engine temperature? Leaking radiator? Gas pump? Dead battery? Wet spark plugs (on older models)? But there is more — air filter, oil filter, oil change, mechanical parts — these usually resolved by handling car to professionals, and they have to know how system works. You have to understand DOM to resolve web page issue. Understanding how graphic card works would help in resolving webgl issues.

necovek 6y ago
We are not talking about people implementing git the tool. We are talking about people using git as a tool (even though they share the common job title of a software engineer/developer). The OP leads in with how "git cherry-pick" and "git rebase" are hard to use and promises to clear it up with a deep dive. You know, how do I turn the wipers on my car? Or turn signals? > You have to understand DOM to resolve web page issue. Understanding how graphic card works would help in resolving webgl issues. As a developer working to build things with DOM, you have to understand the DOM APIs and model. You do not have to understand how DOM is _implemented_ in browsers today and how they achieve things you need when you call the APIs. Sure, there are gotchas that are useful to know ("this CSS selector takes O(n^2) time to match"), but they are the exception, not the rule. Similar holds for WebGL: you need to know the APIs and how to use them effectively. Sure, it's good to know where some of the gotchas are ("this might re-render the whole thing on-screen introducing flicker, here's the off-screen version"), but it's not a blocker. But, none of these require you to understand internal implementation details to effectively use the public APIs (which with git are CLI commands). This is not to say that understanding the nitty-gritty details of anything is a bad thing: it is a GREAT thing, and will probably empower you to do ever more intricate things (and it is usually a very rewarding exercise to learn more about a tool you use)! But that's different from having to know the internals to do the most basic of things (which I'd argue "cherry-pick" and "rebase" are).
- sergeykish 6y ago
  With DOM, you have to know that it is tree. Or you'd be surprised that `append` changes parent. You have to understand reflow, you have to understand stacking, lots and lots of things. A lot of people use DOM without understanding, a lot of people use git without understanding. In both cases one requires some knowledge to resolve issue. And git is trivial, it stores snapshots, nothing hard there. It is interesting, but does not help with `cherry-pick` and `rebase`. The only hard thing about git is recovering — git reflog — easily avoided with backup branches `git branch foo`. Some kind of undo could be useful for beginners to avoid fear of screwing things up. Git has a different mindset from SVN — commits are cheap, branches are cheap, experiments produces new branches, cherry-pick them, rebase them, etc, etc, etc.

TeMPOraL 6y ago

There's a difference between implementation details and core abstractions you need to know to understand a device. That git stores data as an immutable DAG with a layer of pointers to attach human-readable names to things, that's not an implementation detail. That's a core abstraction. It's not like knowing the internals of an ICE, it's like knowing a car moves using wheels, that these wheels must touch the ground for the car to be controllable, and some of them must rotate to change the direction of movement. Knowing such "car internals" isn't necessary for you to be able to turn the key and get it to roll - but it is necessary for safe driving. People who didn't master these "car internals" are the ones who speed on wet ground, don't understand safe braking distance, or why their car skids.