7 ms·

Like others, I think telling people to RTFM is unhelpful. The OP already pointed out that the official Git documentation is bad, bad bad. So, already it's not

by ender7 14y ago

Like others, I think telling people to RTFM is unhelpful. The OP already pointed out that the official Git documentation is bad, bad bad. So, already it's not just "RTFM" but "Google around for a decent Git tutorial and hope you pick the right one." Great. Add to this the fact that the Git commands are simply poorly designed. Yes, it is possible to understand what they do after expending a significant amount of time simply learning to think like Linus, but why should we have to do that? I refer you to the gitref.org entry for 'git reset': git reset is probably the most confusing command written by humans. I've been using Git for years, even wrote a book on it and I still get confused by what it is going to do at times. [0] This is not a problem of people not wanting to learn DVCS concepts. This is simply people who don't want to jump through a set of arbitrary, confusing, and completely unnecessary mental hoops in order to get to the DVCS concepts they wanted to use. [0] http://gitref.org/basic/#reset http://gitref.org/basic/#reset (gitref.org is maintained by GitHub)

encoderer 14y ago
> The OP already pointed out that the official Git documentation is bad, bad bad. So, already it's not just "RTFM" but "Google around for a decent Git tutorial and hope you pick the right one." Great. I have a hard time believing that there are scores of software developers out there who have learned their craft enough to want source control but are somehow overwhelmed by the basic task of finding a good Git tutorial. The real impediment that I've observed is developers that certainly could learn Git but don't because they don't see it as a good investment. That's where they're so, so wrong. Git is like power tools for your code. If you embrace and learn it, you'll be much better off for it. Yes, SVN is easier. It's also a lot less powerful. And there's always Mercurial, which is very similar to Git and addresses some of the confusing-API criticism.
- cshesse 14y ago
  Learning Git would be an investment with a much lower cost if it wasn't so terribly obtuse.
  - chris_wot 14y ago
    I don't see that it's obtuse. If you learn the basic concepts (as you have to do when you are a beginner to subversion or CVS) then you shouldn't have much of an issue.
    - chris_wot 14y ago
      Now why would that be voted down? Obtuse means "mentally slow or emotionally insensitive", so that could hardly have been what was meant. I assume that by "obtuse" you meant "hard to understand". So I stand by my comment that if you learn the basics then it shouldn't be that hard to understand!
      - yb66 14y ago
        Actually, like most words, there is more than one meaning. From the OSX dictionary, after the first listed meaning: > difficult to understand : some of the lyrics are a bit obtuse. It also sounds a lot like 'abstruse', which has the correct meaning and no other. Sorry, but if you're going to be pedantic you'd better be right!
      - chris_wot 14y ago
        yb66 - you are hellbound. Not sure why the OS X dictionary would consider obtuse to be the same as abstruse (that's wrong!), but at least I now know what is really meant. Which is what I had assumed was actually meant (if you followed my original comment, then that's what I said!).
- redbad 14y ago
  Stop defending bad design. We can do better than this.
  - aneth4 14y ago
    Here here. Any design that needs to be defended so vociferously and causes so much confusion is clearly flawed. Distributed version control is not as complicated as this.
  - mikescar 14y ago
    Feel free to fork and make it better. Not sure what you want improved though.
- myspy 14y ago
  Tried to learn the basics to manage the code for my thesis. Gave up widely confused. After trying to revert changes, I went back to it, this time trying eGit and playing with the commands. Managed to get it to work, but still struggling with branches and merging of changes into master. The whole time I was thinking if I'm stupid or talentless. The discussion here showed me that git is indeed far from perfect.
- mgkimsal 14y ago
  "...but are somehow overwhelmed by the basic task of finding a good Git tutorial." Ummm.... when you don't know the tool, you're not in a good place to judge what a 'good' tutorial is. This is the same reason we've got generations of bad PHP developers out there - they can't tell what's good or not. "scores of software developers out there who have learned their craft enough to want source control" How many people 'want' to learn source control, and how many people are told 'this is what we use here, go learn it'? I suspect far more of the latter, especially with git. People would not flock to git purely based on the documentation quality. Further, I suspect that had git just been written by some random dude off the street with no major project behind it, it would have never taken off. Using it for Linux kernel work has ensured a sizeable number of people are going to have to use it, whether they like it or not.
  - encoderer 14y ago
    How many kids want to go to school and how many are told by their parents that 'this is what you do so you can be happy and successful later.' I suspect more of the latter. But like leaning Git, earning your education will pay off. Does that mean Git is without flaws? Of course not. And if you want to work to improve it, and release a better version, go for it. But anybody that sticks with SVN and refuses to learn modern DVCS is not somebody I'd hire. Maybe this is a problem on IT-department, line-of-business teams (where most software developers work) but if Bay Area tech companies are a leading indicator, a big majority of Engineers I work with use and love DVCS's like Git and HG and there's not this groundswell of resistance. And while this isn't related to my previous comments: To anybody who has tried Git and ended up "losing work" because of a misunderstanding of the commands, let me assure you: It's actually a lot harder to lose work than you think. Anything you add to the Index (eg git add foo.py) or commit is stored in the Reflog (which is just a DAG). The reflog is garbage collected periodically -- see below for details. Within that window, you can recover any lost state from the reflog. So how long does Git keep things around by default? Intermediate products of conflicted merges - 15 Days Unreachable commits (do a git reset --hard HEAD~1?) - 30 Days Intermediate products of a resolved merge conflict? - 60 Days Everything Else? - At least 90 days.
    - 14y ago
- StavrosK 14y ago
  I started out with VCSes with bzr, which spoiled me very much, as everything's straightforward, it does whatever I want it to do, and it just works. I then moved to git, because it was much faster, but I couldn't handle it. Which command does the equivalent of "bzr revert -r -3"? What do I do to unstage things? What if I want to only revert some files? I don't even remember which of these things I know, because git threw random errors about things while running commands that were supposedly straightforward, or did things I didn't expect. I tried hg for a time, which was much better, but in the end I went back to bzr (hg confused me in merging, with it thinking that "what is this three-way vimdiff window with all the colors? I'll just leave this and examine the files one by one" meant "okay, everything is correct now"). It interoperates with everything, and it's the sanest of the three, so why wouldn't I use something that just works, rather than fight my tools?
  - mattdeboard 14y ago
    > Which command does the equivalent of "bzr revert -r -3"? What do I do to unstage things? What if I want to only revert some files? git has well-documented and simple commands to perform these operations (except if you're talking about reverting some files in a commit, that's not a thing git does afaik? though it might, but I doubt it would be straightforward). If you're confused by hg & git and just wound up back where you were it sounds like you just didn't have the patience to learn a new tool. Either that or you failed to evaluate what each tool did before you tried switching.
  - numeromancer 14y ago
    \sarc{bzr revert -r 3? What does that do? Jeez, bzr is so confusing.} I don't think git's CLI design is that bad, but the commands for quotidian usage are hidden among a large and confusing array of commands for which serve to make git more powerful for the experts. This is also where the manuals are confusing: all the commands are listed, and beginners don't know where to start. It's like a woodwork hobbyist walking into the workshop of an expert carpenter and wondering where in the hell the hammers are. As for subversion, try using it for branching and merging many parallel versions of code for very long and you'll welcome the arrival of git like that of Jesus into a leper colony.
- CJefferson 14y ago
  The problem with git isn't following a tutorial, the problems I have had are nasty corner cases. I have to keep looking up strange a-symmetries, like why does 'git push' push just the current branch, and 'git pull' pull all branches? Then I have to look up how to make 'git pull' pull just the current branch. Also, due to inconsistencies in how commands take branches, I sometimes realise I have a branch called 'origin/stuff', when I meant to do something with stuff on origin. It's also hard to find which branches are tracking what. Of course, you can find the options to do all these things. But there are just so many little things to learnt. The fundamental question is, does the complexity of git come from the power it offers over svn, or does it come from the most terrible UI I think I have ever seen on a command line tool? I think it is the second. I still use git every day, but I think it is putting usability by less computer-savvy users back years.
  - EdiX 14y ago
    > like why does 'git push' push just the current branch, and 'git pull' pull all branches? It's the opposite, "git push" pushes all branches and "git pull" only pulls the current branch. I think it's because push will only do fast-forward merges while pull will do any merge, and that could require a working directory to exist (but why not make push just push the current branch?)
    - CJefferson 14y ago
      Sorry yes, I got the asymmetry the wrong way around :) The problem this causes (for me) is that if I have commits in other branches, 'git push' will fail (as other branches can't be fast-forwarded), but 'git pull' won't fix it. Of course, I can get around it, but it's annoying.
      - encoderer 14y ago
        What you mean when you say "you can get around it" is just specifying the branch you want to push. Just sayin'. It's not like you have to muck with settings and jump hoops.
      - 14y ago
retrogradeorbit 14y ago
> but _why should we have to do that?_ This is exactly my feeling. Sure, I can, but why should I? I just want to get work done, not become a git fanboy. The place I work at compared DVCSs and chose mercurial, and I'm very happy, I've never looked back, and heres the point... I really have no understanding of HOW mercurial works. It just works.

by ender7 14y ago

encoderer 14y ago

> The OP already pointed out that the official Git documentation is bad, bad bad. So, already it's not just "RTFM" but "Google around for a decent Git tutorial and hope you pick the right one." Great. I have a hard time believing that there are scores of software developers out there who have learned their craft enough to want source control but are somehow overwhelmed by the basic task of finding a good Git tutorial. The real impediment that I've observed is developers that certainly could learn Git but don't because they don't see it as a good investment. That's where they're so, so wrong. Git is like power tools for your code. If you embrace and learn it, you'll be much better off for it. Yes, SVN is easier. It's also a lot less powerful. And there's always Mercurial, which is very similar to Git and addresses some of the confusing-API criticism.

cshesse 14y ago
Learning Git would be an investment with a much lower cost if it wasn't so terribly obtuse.
- chris_wot 14y ago
  I don't see that it's obtuse. If you learn the basic concepts (as you have to do when you are a beginner to subversion or CVS) then you shouldn't have much of an issue.
  - chris_wot 14y ago
    Now why would that be voted down? Obtuse means "mentally slow or emotionally insensitive", so that could hardly have been what was meant. I assume that by "obtuse" you meant "hard to understand". So I stand by my comment that if you learn the basics then it shouldn't be that hard to understand!
    - yb66 14y ago
      Actually, like most words, there is more than one meaning. From the OSX dictionary, after the first listed meaning: > difficult to understand : some of the lyrics are a bit obtuse. It also sounds a lot like 'abstruse', which has the correct meaning and no other. Sorry, but if you're going to be pedantic you'd better be right!
    - chris_wot 14y ago
      yb66 - you are hellbound. Not sure why the OS X dictionary would consider obtuse to be the same as abstruse (that's wrong!), but at least I now know what is really meant. Which is what I had assumed was actually meant (if you followed my original comment, then that's what I said!).
redbad 14y ago
Stop defending bad design. We can do better than this.
- aneth4 14y ago
  Here here. Any design that needs to be defended so vociferously and causes so much confusion is clearly flawed. Distributed version control is not as complicated as this.
- mikescar 14y ago
  Feel free to fork and make it better. Not sure what you want improved though.
myspy 14y ago
Tried to learn the basics to manage the code for my thesis. Gave up widely confused. After trying to revert changes, I went back to it, this time trying eGit and playing with the commands. Managed to get it to work, but still struggling with branches and merging of changes into master. The whole time I was thinking if I'm stupid or talentless. The discussion here showed me that git is indeed far from perfect.
mgkimsal 14y ago
"...but are somehow overwhelmed by the basic task of finding a good Git tutorial." Ummm.... when you don't know the tool, you're not in a good place to judge what a 'good' tutorial is. This is the same reason we've got generations of bad PHP developers out there - they can't tell what's good or not. "scores of software developers out there who have learned their craft enough to want source control" How many people 'want' to learn source control, and how many people are told 'this is what we use here, go learn it'? I suspect far more of the latter, especially with git. People would not flock to git purely based on the documentation quality. Further, I suspect that had git just been written by some random dude off the street with no major project behind it, it would have never taken off. Using it for Linux kernel work has ensured a sizeable number of people are going to have to use it, whether they like it or not.
- encoderer 14y ago
  How many kids want to go to school and how many are told by their parents that 'this is what you do so you can be happy and successful later.' I suspect more of the latter. But like leaning Git, earning your education will pay off. Does that mean Git is without flaws? Of course not. And if you want to work to improve it, and release a better version, go for it. But anybody that sticks with SVN and refuses to learn modern DVCS is not somebody I'd hire. Maybe this is a problem on IT-department, line-of-business teams (where most software developers work) but if Bay Area tech companies are a leading indicator, a big majority of Engineers I work with use and love DVCS's like Git and HG and there's not this groundswell of resistance. And while this isn't related to my previous comments: To anybody who has tried Git and ended up "losing work" because of a misunderstanding of the commands, let me assure you: It's actually a lot harder to lose work than you think. Anything you add to the Index (eg git add foo.py) or commit is stored in the Reflog (which is just a DAG). The reflog is garbage collected periodically -- see below for details. Within that window, you can recover any lost state from the reflog. So how long does Git keep things around by default? Intermediate products of conflicted merges - 15 Days Unreachable commits (do a git reset --hard HEAD~1?) - 30 Days Intermediate products of a resolved merge conflict? - 60 Days Everything Else? - At least 90 days.
  - 14y ago
StavrosK 14y ago
I started out with VCSes with bzr, which spoiled me very much, as everything's straightforward, it does whatever I want it to do, and it just works. I then moved to git, because it was much faster, but I couldn't handle it. Which command does the equivalent of "bzr revert -r -3"? What do I do to unstage things? What if I want to only revert some files? I don't even remember which of these things I know, because git threw random errors about things while running commands that were supposedly straightforward, or did things I didn't expect. I tried hg for a time, which was much better, but in the end I went back to bzr (hg confused me in merging, with it thinking that "what is this three-way vimdiff window with all the colors? I'll just leave this and examine the files one by one" meant "okay, everything is correct now"). It interoperates with everything, and it's the sanest of the three, so why wouldn't I use something that just works, rather than fight my tools?
- mattdeboard 14y ago
  > Which command does the equivalent of "bzr revert -r -3"? What do I do to unstage things? What if I want to only revert some files? git has well-documented and simple commands to perform these operations (except if you're talking about reverting some files in a commit, that's not a thing git does afaik? though it might, but I doubt it would be straightforward). If you're confused by hg & git and just wound up back where you were it sounds like you just didn't have the patience to learn a new tool. Either that or you failed to evaluate what each tool did before you tried switching.
- numeromancer 14y ago
  \sarc{bzr revert -r 3? What does that do? Jeez, bzr is so confusing.} I don't think git's CLI design is that bad, but the commands for quotidian usage are hidden among a large and confusing array of commands for which serve to make git more powerful for the experts. This is also where the manuals are confusing: all the commands are listed, and beginners don't know where to start. It's like a woodwork hobbyist walking into the workshop of an expert carpenter and wondering where in the hell the hammers are. As for subversion, try using it for branching and merging many parallel versions of code for very long and you'll welcome the arrival of git like that of Jesus into a leper colony.
CJefferson 14y ago
The problem with git isn't following a tutorial, the problems I have had are nasty corner cases. I have to keep looking up strange a-symmetries, like why does 'git push' push just the current branch, and 'git pull' pull all branches? Then I have to look up how to make 'git pull' pull just the current branch. Also, due to inconsistencies in how commands take branches, I sometimes realise I have a branch called 'origin/stuff', when I meant to do something with stuff on origin. It's also hard to find which branches are tracking what. Of course, you can find the options to do all these things. But there are just so many little things to learnt. The fundamental question is, does the complexity of git come from the power it offers over svn, or does it come from the most terrible UI I think I have ever seen on a command line tool? I think it is the second. I still use git every day, but I think it is putting usability by less computer-savvy users back years.
- EdiX 14y ago
  > like why does 'git push' push just the current branch, and 'git pull' pull all branches? It's the opposite, "git push" pushes all branches and "git pull" only pulls the current branch. I think it's because push will only do fast-forward merges while pull will do any merge, and that could require a working directory to exist (but why not make push just push the current branch?)
  - CJefferson 14y ago
    Sorry yes, I got the asymmetry the wrong way around :) The problem this causes (for me) is that if I have commits in other branches, 'git push' will fail (as other branches can't be fast-forwarded), but 'git pull' won't fix it. Of course, I can get around it, but it's annoying.
    - encoderer 14y ago
      What you mean when you say "you can get around it" is just specifying the branch you want to push. Just sayin'. It's not like you have to muck with settings and jump hoops.
    - 14y ago

retrogradeorbit 14y ago

> but _why should we have to do that?_ This is exactly my feeling. Sure, I can, but why should I? I just want to get work done, not become a git fanboy. The place I work at compared DVCSs and chose mercurial, and I'm very happy, I've never looked back, and heres the point... I really have no understanding of HOW mercurial works. It just works.