8 ms·

Git Reset Demystified

126 points by schacon 15y ago

senko 15y ago
Good overview, for beginners as well as regular users. In particular git checkout <file> which is (a) not obvious (before stumbling upon it, I was trying to find it in git-reset documentation), and (b) looks pretty innocent (as the git checkout branch is quite safe to do if you've got staged changes.)
skrebbel 15y ago
Everytime I see an article like this, of this length, all to explain a single git command, I get the feeling that git (and all other decent SCM tools at that) are way too complex. It's well written and well illustrated, but I feel like I shouldn't have to read that much just to learn a basic feature of a tool that's supposed to exist to help me. Is this just me? Of course, the feeling is strengthened by the fact that I still don't completely grok git, but shouldn't a tool that's there to help me be easier to grok? I understood dropbox in 1 minute. I learnt TDD in 3 hours. Why should (distributed) version control be so much more difficult? I don't know how, just wondering if I'm the only guy who feels like this.
- spacemanaki 15y ago
  You're not, and I think this is where a lot of flamewars between Git and Mercurial users and between DVCS and centralized VCS users start, so I while I don't want to feed the fire, I will only cautiously recommend peeking at Joel Spolsky's Hg Init tutorial, and see if Mercurial is a bit more natural for you, since a lot of people seem to think it's simpler (I have no opinion, mostly because I haven't used Mercurial much). At the end of the day, for me it boils down to a comment by Xiong Chiamiov, made on one of Mike Taylor's rant-y blogposts about Git, which was much discussed on HN a while ago, "I use it because the benefits outweigh all of the things that you mentioned." Yeah, it's complicated. But a lot of people think it's worth it. edited to add links to the Reinvigorated Programmer posts, which I recommend reading because there's a ton of good commentary and suggestions for newcomers, even if the discussion got a bit heated: http://reprog.wordpress.com/2010/05/10/git-is-a-harrier-jump-jet-and-not-in-a-good-way/ http://reprog.wordpress.com/2010/05/10/git-is-a-harrier-jump... http://reprog.wordpress.com/2010/05/12/still-hatin-on-git-now-with-added-actual-reasons/ http://reprog.wordpress.com/2010/05/12/still-hatin-on-git-no...
  - skrebbel 15y ago
    Thanks for the advice. However, I felt exactly the same with Hg. In fact, the main reason I have for currently using git and not hg is github. I'm convinced that indeed it's worth spending more time to grok [git/hg/bzr] and really get the power out of it, but I just can't shake the feeling that somehow, it should be possible to make something with the same benefits that works much easier. I was hoping that maybe Kiln is exactly that, but from their promo-page all I can see is a rant about how cool DVCSs are, and not much about how Kiln makes Hg easier.
    - spacemanaki 15y ago
      I use Git for the same reason, although there's also Bitbucket and others for Hg. I don't want to act as an apologist for Git, because I think the user-interface could use some work (although I gather it was much worse earlier). I think at the end of the "Git from the bottom up" tutorial the author wishes the interface were better, but believes that Git will be the base upon which awesome things will be built. I don't know if anyone has tried to create a kind of porcelain-above-the-porcelain of Git, but that might be interesting, although from my experience with 3rd party Git GUI tools (Tortoise, EGit), many of which abstract details away, it can also be infuriating if done poorly. I don't think the current DVCS are the best thing ever possible, but I do think Git one of the best things we have now.
    - sjs 15y ago
      Here's the key to git: embrace the fact that you're going to learn a new tool. Learn how to use it and play around with it. Once you're comfortable doing the basic things you would do day to day like create a repo, commit, push, pull, branch, merge, etc. then dig in deeper. Now you start reading about how git works under the hood to demystify the things you already know. Articles like "Git for Computer Scientists" are great at this stage. Once you know how git's incredibly simple model works you are well poised to learn more advanced things. Rebasing can be hard for some people to understand and it's even harder if you don't know what commits and branches actually are. After that you need little instruction and should be able to help yourself. It's totally worth it and it's not as hard as you think! edit: Plus once you know how it works you get to skip big parts of articles like this and just skim around to pick up what you don't already know. It's pretty light reading actually.
- 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.
- chrisledet 15y ago
  TDD isn't a tool, it's a process of developing software. This is just the internal stuff, you DONT need to know this using git on a day to day basis. I use git for all my projects and most of the time, i mainly just type `git commit -a -m "lol message" && git push`. Do you need to know everything about MS Word in order to become productive with it? No. Apply the same concept to Git or any software really.
  - skrebbel 15y ago
    True that, and that's what I do (well, I don't type that command but I right-click in Explorer and choose Git Commit, but I see your point). I guess the difference is that if there's something that Word can do that I want to figure out, there's good Help and I can get pretty far by scanning the menus. With git, good help exists too (in the form of blog posts like this article), except that the concepts are significantly more complex than those involved in making automatically numbered chapter headings. In short, to my experience figuring out how to do something non-trivial with Word is exploration. Figuring out how to do something non-trivial with Git is more like studying an advanced CS class.
- Jach 15y ago
  In this case it's a difference in levels of understanding. From the beginning of the article: "I never strongly understood the command beyond the handful of specific use cases that I needed it for." So in that frame of mind git-reset is very simple. "Oh crap, I messed up my working dir and everything's messed up! git-reset --hard!" The purpose of the article though is to improve understanding beyond that and at an intuitive level. It's the difference between saying Bayes Theorem is p(h|e,c) = p(e|h,c)*p(h|c)/p(e|c) and linking to http://commonsenseatheism.com/?p=13156 http://commonsenseatheism.com/?p=13156 The thing I like about git is that yes, as a whole it's pretty complicated, but it's really not that hard to get up and running quickly especially if you use github. Then it's a gift that keeps on giving as you learn more about it while also becoming more proficient. Kind of like vim in a way, which is notorious for its wall of a learning curve, but if you just want to treat it as a normal text editor you can tell it to start up in insert mode and use gvim, then proceed to learn from there.
  - cpeterso 15y ago
    > From the beginning of the article: "I never strongly understood the command beyond the handful of specific use cases that I needed it for." Note that this comment was written by the author of one of the most popular git books (Pro Git)! His dead tree book is #88 among Amazon's Software Development books. His Kindle book is #16 among Amazon's Software Development Kindle books.
- silon 15y ago
  Git is not wrong by itself, there's just an impedance mismatch between it's model and a usable interface model. For most purposes, the index should completely hidden.
  - urschrei 15y ago
    I would respectfully allow that anyone who can't comprehend what the index is for with the aid of two paragraphs and a diagram should be looking for an alternate career. The index is important. It's one of the great things about Git; without it, you wouldn't be able to create commits from a subset of the difference between your working directory and HEAD. It also has a confusing name, but here we are.
    - bronson 15y ago
      It's also vital when merging. Agreed, too bad about the naming problem. Index, cache, staging Area... how many names does it need?
    - wcoenen 15y ago
      I appreciate that you should have the option to choose which part of your working directory you commit. But I think the default should be to commit everything, like in SVN or mercurial. If I need to commit selectively in those systems, I'll disable some checkboxes, type in the filenames, build a changelist or use the record extension or something. The point is that I don't need to deal with it until I need it. Also, it seems to me that git's behaviour encourages broken revisions (i.e. compiler errors, test failures) because your working directory doesn't match what you commit. And broken revisions will interfere with bisecting.
      - epochwolf 15y ago
        Git requires a bit of a learning curve to use but it's gotten far simpler than subversion for me. I used subversion for years before using git. I refuse to go back. If you always want to commit everything use `git add . && git commit -a`.
      - 15y ago
- rlpb 15y ago
  For me, git is remarkably simple. Its underlying data model is all that you need to understand (and there are only about four major types of object). Everything about SCM then pops out. I found myself needing tools to manipulate the data model in some way, and a suitable tool always seems to exist. It's kind of like the Grand Unified Theory of SCM. With such a simple core, everything about SCM just falls out. I prefer to understand everything in this way so git is perfect for me. But I can understand that it's probably far trickier for people who prefer to learn top-down by starting with workflow and processes rather than from first principles from bottom-up.
- dkarl 15y ago
  It can take a long time to understand something simple but alien. The advantages of familiarity are short-term; the advantages of simplicity are forever.
- ajross 15y ago
  Sure, but there are already "tools to help you" in this realm that are easier to grok. Early on, developers saved old versions of code via manual copying. That was really easy to grok (Label floppy with "1983 Aug 12", copy, put in box). But it sucked. So developers invented things like SCCS or RCS, which stored metadata. But they were harder to grok, as now you had to understand the idea of files having history (and branches), and needing to be "checked out" using tools entirely different from standard copying, and being "locked" against change. But they helped, even though they still kind of sucked. So hackers invented CVS and Subversion, which worked on trees instead of files, used implicit locking and merge algorithms, and generally made life better. But they were yet harder to grok! Now doing regular development meant that occasionally you'd get collisions: you needed to understand the 3-way merge algorithm just to write code. And they still sucked. So Linus gave us git. Which adds a bunch of new hard-to-grok abstractions like the index and commit ID. But it fixes a bunch of problems too, even if 10 years from now we'll agree that it sucked too. So pick your point along that spectrum and choose your tool to match your comfort level. In short: your complaints aren't anything new, SCM systems have always been confusing to learn.
  - gcr 15y ago
    Why did everything suck? Are we even addressing the problems as we trudge along your linear development path? I think what your parent was getting at is that increasing complexity of SCM software is orthogonal to the problem, which hasn't really been defined well. It's easy to say that something sucks, but it's harder to say why.
- beza1e1 15y ago
  Git is fundamentally pretty easy, but its terminology is confusing. Maybe this glossary helps: commit: a snapshot of your files tag: a reference to a commit branch: a moving tag HEAD: the current branch index: the next unfinished commit git-add: copy file(s) to index git-commit: create a commit from the index git-checkout: copy file(s) from a commit and redirect HEAD git-reset: redirect current branch to another commit git-revert: create new commit, which is the inverse of another commit An interesting thing is that "the next commit" is an object you can work with in git. This concept is new for svn users. With git you can puzzle together a snapshot before it becomes a "real" commit. So mistakes like "Oops, i should not have commited that file" or "Oops, i forgot a little fix in another file" can be handled with git.
- sliverstorm 15y ago
  I personally feel the problem is just the terminology doesn't really match between tools. Coming from SVN, I think of something I want to do and I think of the SVN command for it, but it turns out the Git command is a totally different name, so I spend 10-20 minutes being confused- especially when there is a command of the same name that does something different.
- a3_nm 15y ago
  I agree with you. It seems like the basic concepts are neat and clean, but that the interface to it, and the vocabulary, is counter-intuitive. The article really gives me the impression that git-reset can be used to do several vaguely related things, with an inadequate terminology (--soft, --mixed, --hard?). Besides, it doesn't help that the first commands you learn about git (like git add, git commit -a, etc.) actually hide most of the complexity in a treacherous way (especially since they do not advertise the existence of the index). It's probably possible to learn git efficiently by approaching it as something abstract, not as that stuff you want to be quickly productive with. Sadly, you probably can't realize that unless you already wasted your time on the misleading tutorials.
- saraid216 15y ago
  Git is more comparable to Vi or Emacs than Dropbox or TDD. Or compare it to grep or sed. The article is intended for deep understanding, not as a tutorial.
spacemanaki 15y ago
Scott, thank you so much for all your work on Git tutorials, blog posts, screencasts and books... I'm sure you know this already but you're a great teacher!
- devth 15y ago
  I second that. Pure excellence at http://progit.org/ http://progit.org/
deleted 15y ago
[deleted]
zby 15y ago
git is an extremely powerful tool - but it's interface is far from being smooth - maybe it will come with time. For example the usual pattern of a copy command is: copy source destination The pattern of git push command push destination source:destination
- fr0sty 15y ago
  1. There is no built-in copy command in git. 2. What is confusing about "git push <remoterepository> <localbranch>:<remotebranch>"
yason 15y ago
Git is like that "one data structure with a hundred functions operating on it, instead of ten functions operating on ten data structures".
- beza1e1 15y ago
  And that "one data structure" is a directed acyclic graph of objects, where an object is one of four kinds: - blob (like a file) - tree (referencing trees and/or blobs, like a directory) - commit (referencing one tree and other commits) - tag (referencing a commit)
andrewflnr 15y ago
It's ironic that this is on the front page at the same time as Linus's proposal to change to commit object format, in which he claims that the lack of generation numbers is Git's "only real design flaw" [1]. Okay, maybe he's only talking about the plumbing, but if it needs long guides like this to understand one command, I think maybe that would constitute a design flaw. I like Git, I really do. This article helped me like it more. There has to be a way to get the benefit of that object model without all the grief at the interface. [1] http://news.ycombinator.com/item?id=2765844 http://news.ycombinator.com/item?id=2765844

126 points by schacon 15y ago

senko 15y ago

Good overview, for beginners as well as regular users. In particular git checkout <file> which is (a) not obvious (before stumbling upon it, I was trying to find it in git-reset documentation), and (b) looks pretty innocent (as the git checkout branch is quite safe to do if you've got staged changes.)

skrebbel 15y ago

Everytime I see an article like this, of this length, all to explain a single git command, I get the feeling that git (and all other decent SCM tools at that) are way too complex. It's well written and well illustrated, but I feel like I shouldn't have to read that much just to learn a basic feature of a tool that's supposed to exist to help me. Is this just me? Of course, the feeling is strengthened by the fact that I still don't completely grok git, but shouldn't a tool that's there to help me be easier to grok? I understood dropbox in 1 minute. I learnt TDD in 3 hours. Why should (distributed) version control be so much more difficult? I don't know how, just wondering if I'm the only guy who feels like this.

spacemanaki 15y ago
You're not, and I think this is where a lot of flamewars between Git and Mercurial users and between DVCS and centralized VCS users start, so I while I don't want to feed the fire, I will only cautiously recommend peeking at Joel Spolsky's Hg Init tutorial, and see if Mercurial is a bit more natural for you, since a lot of people seem to think it's simpler (I have no opinion, mostly because I haven't used Mercurial much). At the end of the day, for me it boils down to a comment by Xiong Chiamiov, made on one of Mike Taylor's rant-y blogposts about Git, which was much discussed on HN a while ago, "I use it because the benefits outweigh all of the things that you mentioned." Yeah, it's complicated. But a lot of people think it's worth it. edited to add links to the Reinvigorated Programmer posts, which I recommend reading because there's a ton of good commentary and suggestions for newcomers, even if the discussion got a bit heated: http://reprog.wordpress.com/2010/05/10/git-is-a-harrier-jump-jet-and-not-in-a-good-way/ http://reprog.wordpress.com/2010/05/10/git-is-a-harrier-jump... http://reprog.wordpress.com/2010/05/12/still-hatin-on-git-now-with-added-actual-reasons/ http://reprog.wordpress.com/2010/05/12/still-hatin-on-git-no...
- skrebbel 15y ago
  Thanks for the advice. However, I felt exactly the same with Hg. In fact, the main reason I have for currently using git and not hg is github. I'm convinced that indeed it's worth spending more time to grok [git/hg/bzr] and really get the power out of it, but I just can't shake the feeling that somehow, it should be possible to make something with the same benefits that works much easier. I was hoping that maybe Kiln is exactly that, but from their promo-page all I can see is a rant about how cool DVCSs are, and not much about how Kiln makes Hg easier.
  - spacemanaki 15y ago
    I use Git for the same reason, although there's also Bitbucket and others for Hg. I don't want to act as an apologist for Git, because I think the user-interface could use some work (although I gather it was much worse earlier). I think at the end of the "Git from the bottom up" tutorial the author wishes the interface were better, but believes that Git will be the base upon which awesome things will be built. I don't know if anyone has tried to create a kind of porcelain-above-the-porcelain of Git, but that might be interesting, although from my experience with 3rd party Git GUI tools (Tortoise, EGit), many of which abstract details away, it can also be infuriating if done poorly. I don't think the current DVCS are the best thing ever possible, but I do think Git one of the best things we have now.
  - sjs 15y ago
    Here's the key to git: embrace the fact that you're going to learn a new tool. Learn how to use it and play around with it. Once you're comfortable doing the basic things you would do day to day like create a repo, commit, push, pull, branch, merge, etc. then dig in deeper. Now you start reading about how git works under the hood to demystify the things you already know. Articles like "Git for Computer Scientists" are great at this stage. Once you know how git's incredibly simple model works you are well poised to learn more advanced things. Rebasing can be hard for some people to understand and it's even harder if you don't know what commits and branches actually are. After that you need little instruction and should be able to help yourself. It's totally worth it and it's not as hard as you think! edit: Plus once you know how it works you get to skip big parts of articles like this and just skim around to pick up what you don't already know. It's pretty light reading actually.
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.
chrisledet 15y ago
TDD isn't a tool, it's a process of developing software. This is just the internal stuff, you DONT need to know this using git on a day to day basis. I use git for all my projects and most of the time, i mainly just type `git commit -a -m "lol message" && git push`. Do you need to know everything about MS Word in order to become productive with it? No. Apply the same concept to Git or any software really.
- skrebbel 15y ago
  True that, and that's what I do (well, I don't type that command but I right-click in Explorer and choose Git Commit, but I see your point). I guess the difference is that if there's something that Word can do that I want to figure out, there's good Help and I can get pretty far by scanning the menus. With git, good help exists too (in the form of blog posts like this article), except that the concepts are significantly more complex than those involved in making automatically numbered chapter headings. In short, to my experience figuring out how to do something non-trivial with Word is exploration. Figuring out how to do something non-trivial with Git is more like studying an advanced CS class.
Jach 15y ago
In this case it's a difference in levels of understanding. From the beginning of the article: "I never strongly understood the command beyond the handful of specific use cases that I needed it for." So in that frame of mind git-reset is very simple. "Oh crap, I messed up my working dir and everything's messed up! git-reset --hard!" The purpose of the article though is to improve understanding beyond that and at an intuitive level. It's the difference between saying Bayes Theorem is p(h|e,c) = p(e|h,c)*p(h|c)/p(e|c) and linking to http://commonsenseatheism.com/?p=13156 http://commonsenseatheism.com/?p=13156 The thing I like about git is that yes, as a whole it's pretty complicated, but it's really not that hard to get up and running quickly especially if you use github. Then it's a gift that keeps on giving as you learn more about it while also becoming more proficient. Kind of like vim in a way, which is notorious for its wall of a learning curve, but if you just want to treat it as a normal text editor you can tell it to start up in insert mode and use gvim, then proceed to learn from there.
- cpeterso 15y ago
  > From the beginning of the article: "I never strongly understood the command beyond the handful of specific use cases that I needed it for." Note that this comment was written by the author of one of the most popular git books (Pro Git)! His dead tree book is #88 among Amazon's Software Development books. His Kindle book is #16 among Amazon's Software Development Kindle books.
silon 15y ago
Git is not wrong by itself, there's just an impedance mismatch between it's model and a usable interface model. For most purposes, the index should completely hidden.
- urschrei 15y ago
  I would respectfully allow that anyone who can't comprehend what the index is for with the aid of two paragraphs and a diagram should be looking for an alternate career. The index is important. It's one of the great things about Git; without it, you wouldn't be able to create commits from a subset of the difference between your working directory and HEAD. It also has a confusing name, but here we are.
  - bronson 15y ago
    It's also vital when merging. Agreed, too bad about the naming problem. Index, cache, staging Area... how many names does it need?
  - wcoenen 15y ago
    I appreciate that you should have the option to choose which part of your working directory you commit. But I think the default should be to commit everything, like in SVN or mercurial. If I need to commit selectively in those systems, I'll disable some checkboxes, type in the filenames, build a changelist or use the record extension or something. The point is that I don't need to deal with it until I need it. Also, it seems to me that git's behaviour encourages broken revisions (i.e. compiler errors, test failures) because your working directory doesn't match what you commit. And broken revisions will interfere with bisecting.
    - epochwolf 15y ago
      Git requires a bit of a learning curve to use but it's gotten far simpler than subversion for me. I used subversion for years before using git. I refuse to go back. If you always want to commit everything use `git add . && git commit -a`.
    - 15y ago
rlpb 15y ago
For me, git is remarkably simple. Its underlying data model is all that you need to understand (and there are only about four major types of object). Everything about SCM then pops out. I found myself needing tools to manipulate the data model in some way, and a suitable tool always seems to exist. It's kind of like the Grand Unified Theory of SCM. With such a simple core, everything about SCM just falls out. I prefer to understand everything in this way so git is perfect for me. But I can understand that it's probably far trickier for people who prefer to learn top-down by starting with workflow and processes rather than from first principles from bottom-up.
dkarl 15y ago
It can take a long time to understand something simple but alien. The advantages of familiarity are short-term; the advantages of simplicity are forever.
ajross 15y ago
Sure, but there are already "tools to help you" in this realm that are easier to grok. Early on, developers saved old versions of code via manual copying. That was really easy to grok (Label floppy with "1983 Aug 12", copy, put in box). But it sucked. So developers invented things like SCCS or RCS, which stored metadata. But they were harder to grok, as now you had to understand the idea of files having history (and branches), and needing to be "checked out" using tools entirely different from standard copying, and being "locked" against change. But they helped, even though they still kind of sucked. So hackers invented CVS and Subversion, which worked on trees instead of files, used implicit locking and merge algorithms, and generally made life better. But they were yet harder to grok! Now doing regular development meant that occasionally you'd get collisions: you needed to understand the 3-way merge algorithm just to write code. And they still sucked. So Linus gave us git. Which adds a bunch of new hard-to-grok abstractions like the index and commit ID. But it fixes a bunch of problems too, even if 10 years from now we'll agree that it sucked too. So pick your point along that spectrum and choose your tool to match your comfort level. In short: your complaints aren't anything new, SCM systems have always been confusing to learn.
- gcr 15y ago
  Why did everything suck? Are we even addressing the problems as we trudge along your linear development path? I think what your parent was getting at is that increasing complexity of SCM software is orthogonal to the problem, which hasn't really been defined well. It's easy to say that something sucks, but it's harder to say why.
beza1e1 15y ago
Git is fundamentally pretty easy, but its terminology is confusing. Maybe this glossary helps: commit: a snapshot of your files tag: a reference to a commit branch: a moving tag HEAD: the current branch index: the next unfinished commit git-add: copy file(s) to index git-commit: create a commit from the index git-checkout: copy file(s) from a commit and redirect HEAD git-reset: redirect current branch to another commit git-revert: create new commit, which is the inverse of another commit An interesting thing is that "the next commit" is an object you can work with in git. This concept is new for svn users. With git you can puzzle together a snapshot before it becomes a "real" commit. So mistakes like "Oops, i should not have commited that file" or "Oops, i forgot a little fix in another file" can be handled with git.
sliverstorm 15y ago
I personally feel the problem is just the terminology doesn't really match between tools. Coming from SVN, I think of something I want to do and I think of the SVN command for it, but it turns out the Git command is a totally different name, so I spend 10-20 minutes being confused- especially when there is a command of the same name that does something different.
a3_nm 15y ago
I agree with you. It seems like the basic concepts are neat and clean, but that the interface to it, and the vocabulary, is counter-intuitive. The article really gives me the impression that git-reset can be used to do several vaguely related things, with an inadequate terminology (--soft, --mixed, --hard?). Besides, it doesn't help that the first commands you learn about git (like git add, git commit -a, etc.) actually hide most of the complexity in a treacherous way (especially since they do not advertise the existence of the index). It's probably possible to learn git efficiently by approaching it as something abstract, not as that stuff you want to be quickly productive with. Sadly, you probably can't realize that unless you already wasted your time on the misleading tutorials.
saraid216 15y ago
Git is more comparable to Vi or Emacs than Dropbox or TDD. Or compare it to grep or sed. The article is intended for deep understanding, not as a tutorial.

spacemanaki 15y ago

Scott, thank you so much for all your work on Git tutorials, blog posts, screencasts and books... I'm sure you know this already but you're a great teacher!

devth 15y ago
I second that. Pure excellence at http://progit.org/ http://progit.org/

deleted 15y ago

[deleted]

zby 15y ago

git is an extremely powerful tool - but it's interface is far from being smooth - maybe it will come with time. For example the usual pattern of a copy command is: copy source destination The pattern of git push command push destination source:destination

fr0sty 15y ago
1. There is no built-in copy command in git. 2. What is confusing about "git push <remoterepository> <localbranch>:<remotebranch>"

yason 15y ago

Git is like that "one data structure with a hundred functions operating on it, instead of ten functions operating on ten data structures".

beza1e1 15y ago
And that "one data structure" is a directed acyclic graph of objects, where an object is one of four kinds: - blob (like a file) - tree (referencing trees and/or blobs, like a directory) - commit (referencing one tree and other commits) - tag (referencing a commit)

andrewflnr 15y ago

It's ironic that this is on the front page at the same time as Linus's proposal to change to commit object format, in which he claims that the lack of generation numbers is Git's "only real design flaw" [1]. Okay, maybe he's only talking about the plumbing, but if it needs long guides like this to understand one command, I think maybe that would constitute a design flaw. I like Git, I really do. This article helped me like it more. There has to be a way to get the benefit of that object model without all the grief at the interface. [1] http://news.ycombinator.com/item?id=2765844 http://news.ycombinator.com/item?id=2765844