5 ms·

It is more that the git API uses terms that have been used in past VCSes in different ways, so it is a matter of helping new users to unlearn their original men

by Xurinos 15y ago

It is more that the git API uses terms that have been used in past VCSes in different ways, so it is a matter of helping new users to unlearn their original mental model from older VCSes and to learn the new model. I am mostly convinced that the new definitions of terms are more accurate. "git reset" in one sentence: git reset allows you to move the HEAD's branch tag to any other git revision. (It is easiest to think about git in terms of labels moving around a tree of nodes.)

skrebbel 15y ago
There you go. What's a "branch tag"? What do labels do in "trees of nodes"? Mind, I don't mind tackling this kind of complexity when I do algorithms for getting something done. I'm perfectly capable of understanding what you mean if I'd really invest the time in it that I should. But why do I need to do such (relatively) complex yet abstract thinking when I want store a README, undo a mistake and then share it all with a colleague?
- spacemanaki 15y ago
  > What's a "branch tag"? What do labels do in "trees of nodes"? I'd recommend "Git from the bottom up" or Scott Chacon's "Getting Git" screencast. Both tackle Git for newcomers by describing the underlying data structures. Once I had a cursory overview of what Git was actually doing under the hood, so much else clicked for me.
- Xurinos 15y ago
  > why do I need to do such (relatively) complex yet abstract > thinking when I want store a README, undo a mistake, You have a legitimate point, and I think it is because your level of understanding, your need to know, depends on the actions you want to take. At first, it is sufficient to know "git add <new file>" and "git commit -a". You will be challenged as soon as you need to do something beyond the very basic linear, like "git push" and "git pull". Branching, merging, sharing... Version control is just not dirt simple. There is fundamental theory to it. If you work with others, lacking that theory will lead to pain in any VCS (starting with a fear of merges and conflict resolution). These things that you consider simple actions begin to add up, and at some point, your mental model needs to adjust in order to grasp the relationships amongst these things. Your model necessarily becomes more abstract. I am not convinced that that means it is more "complex", at least significantly enough to be a real barrier to moving forward with git.
- sofal 15y ago
  I used to be right there with you. I knew svn and I just wanted to port that knowledge over to git and start working. The problem was that the git interface is similar enough to svn that it lets you use it almost like svn (add, commit, status, checkout, etc) and leads you to believe that it is fundamentally like svn. So whenever the first non-svn thing comes along it suddenly seems way too complicated. It seems like it's svn except with a whole lot of extra complicated crap added on. I told myself I'd eventually climb this gigantic-seeming learning curve, but I kept putting it off because it looked like such a huge obstacle. One day I finally sat down and starting going through the Pro Git book. After reading about the fundamentals of git I finally realized that this is ultimately no more complicated than a first year data structures class. It's just a stupid directed graph. All this wasted time scratching my head, only to find out that it's just a directed graph with labels attached to the nodes called 'branches'. All the crazy git commands with all the crazy options are just hacks that let you look at and fiddle with this stupid graph. Ultimately when you want your repository to be in a certain state, you first figure out what you want the graph to look like and then you use whatever git commands you want to make it so. It's hard to explain how fundamentally simple it is. The actual interface doesn't make it seem like it's simple, and all the terms that everything has doesn't make it seem simple, but it is all a bunch of tools and terminology built on top of a simple data structure. Unlike many tools, it is easier to understand the internals of git than the externals. But once you understand the internals, then you can practically speed read an article like this in the same way you could speed read an article explaining for/while loop syntax.
  - cpeterso 15y ago
    > Unlike many tools, it is easier to understand the internals of git than the externals. But why should that be? For example, the git docs use different terms for the same thing (e.g. cache, index, stage). Also, the git tools overload the same command for different purposes (e.g. git add tracks new files or stages pending changes from existing files; git reset can unstage pending changes or revert committed changes). These are different functional procedures that happen to share implementation details.
    - Xurinos 15y ago

by Xurinos 15y ago

skrebbel 15y ago

There you go. What's a "branch tag"? What do labels do in "trees of nodes"? Mind, I don't mind tackling this kind of complexity when I do algorithms for getting something done. I'm perfectly capable of understanding what you mean if I'd really invest the time in it that I should. But why do I need to do such (relatively) complex yet abstract thinking when I want store a README, undo a mistake and then share it all with a colleague?

spacemanaki 15y ago
> What's a "branch tag"? What do labels do in "trees of nodes"? I'd recommend "Git from the bottom up" or Scott Chacon's "Getting Git" screencast. Both tackle Git for newcomers by describing the underlying data structures. Once I had a cursory overview of what Git was actually doing under the hood, so much else clicked for me.
Xurinos 15y ago
> why do I need to do such (relatively) complex yet abstract > thinking when I want store a README, undo a mistake, You have a legitimate point, and I think it is because your level of understanding, your need to know, depends on the actions you want to take. At first, it is sufficient to know "git add <new file>" and "git commit -a". You will be challenged as soon as you need to do something beyond the very basic linear, like "git push" and "git pull". Branching, merging, sharing... Version control is just not dirt simple. There is fundamental theory to it. If you work with others, lacking that theory will lead to pain in any VCS (starting with a fear of merges and conflict resolution). These things that you consider simple actions begin to add up, and at some point, your mental model needs to adjust in order to grasp the relationships amongst these things. Your model necessarily becomes more abstract. I am not convinced that that means it is more "complex", at least significantly enough to be a real barrier to moving forward with git.
sofal 15y ago
I used to be right there with you. I knew svn and I just wanted to port that knowledge over to git and start working. The problem was that the git interface is similar enough to svn that it lets you use it almost like svn (add, commit, status, checkout, etc) and leads you to believe that it is fundamentally like svn. So whenever the first non-svn thing comes along it suddenly seems way too complicated. It seems like it's svn except with a whole lot of extra complicated crap added on. I told myself I'd eventually climb this gigantic-seeming learning curve, but I kept putting it off because it looked like such a huge obstacle. One day I finally sat down and starting going through the Pro Git book. After reading about the fundamentals of git I finally realized that this is ultimately no more complicated than a first year data structures class. It's just a stupid directed graph. All this wasted time scratching my head, only to find out that it's just a directed graph with labels attached to the nodes called 'branches'. All the crazy git commands with all the crazy options are just hacks that let you look at and fiddle with this stupid graph. Ultimately when you want your repository to be in a certain state, you first figure out what you want the graph to look like and then you use whatever git commands you want to make it so. It's hard to explain how fundamentally simple it is. The actual interface doesn't make it seem like it's simple, and all the terms that everything has doesn't make it seem simple, but it is all a bunch of tools and terminology built on top of a simple data structure. Unlike many tools, it is easier to understand the internals of git than the externals. But once you understand the internals, then you can practically speed read an article like this in the same way you could speed read an article explaining for/while loop syntax.
- cpeterso 15y ago
  > Unlike many tools, it is easier to understand the internals of git than the externals. But why should that be? For example, the git docs use different terms for the same thing (e.g. cache, index, stage). Also, the git tools overload the same command for different purposes (e.g. git add tracks new files or stages pending changes from existing files; git reset can unstage pending changes or revert committed changes). These are different functional procedures that happen to share implementation details.
  - Xurinos 15y ago