7 ms·

> Because, for one thing, "one" sometimes doesn't have the computer science degree and years of experience to even begin to understand Git, for one thing. With

> Because, for one thing, "one" sometimes doesn't have the computer science degree and years of experience to even begin to understand Git, for one thing. With respect, I call shenanigans on this my good friend. I dropped out of highschool and attended no postsecondary and I don't have any problems with Git. I started with the basics and read more as I got myself into tighter and tighter jams. I feel like this myth is perpetuated by a small group of people who are very vocal about "git is hard". If git commit and git checkout are too complicated, I don't know what else to say except that every VCS has those concepts, perhaps you're just used to those systems instead.

k-mcgrady 12y ago
I think git hard a small but steep learning curve. Lots of developers aren't used to using the command line anymore so git can seem 'scary'. Personally I gave up on git a couple of times before finally learning it but as a developer working by myself I also couldn't understand the need for version control (at the time) so giving up wasn't a big deal. I think once you give it a couple of hours of your time you can understand enough to use it in most situations. Plus the GUI tools (SourceTree for example) are quite good.
kazinator 12y ago
> I dropped out of highschool and attended no postsecondary and I don't have any problems with Git. Git problems arise when people want to do moderately sophisticated things, beyond just committing changes and viewing logs and diffs. > If git commit and git checkout are too complicated, If "If git commit and git checkout are too complicated" is your argument, then you aren't doing anything more sophisticated with git than what you learned from a svn to git migration tutorial in five minutes. People do more with version control than "commit and forget". If that's all you need, then what you really want is backup software that takes regular snapshots of your filesystem.
- click170 12y ago
  I think you may have misunderstood my comment, of course there is more to it then checkout and commit. Those are the basics, that's where you start. Then you get stuck somehow, and you read more. That's what I did at least. IMO It's about not giving yourself the impression that the learning curve is insurmountable, you can do it. Starting with the basics and growing up is, I thought, common knowledge for acquiring a new skill. I find when I get confused and flustered with git, every single time it's because I don't understand [yet] how I got into the current state. I've found that if I take a breath, put the problem aside and focus on figuring out how I got into that broken state, then the solution reveals itself -- not once have I ever lost code as a result of git confusion.
  - deleted 12y ago
    [deleted]
  - kazinator 12y ago
    I perfectly understand that there are hordes of programmers for whom messing around with git is far more interesting than the actual code they are working on. "Man, I just interactively rebased my last six changes so the commits are in a different order, and two of them were squashed into one! Boy, does that feel productive."
    - zBard 12y ago
      How is that in anyway a reply to what s/he wrote ? Even snark should have a purpose.
  - srean 12y ago
    > It's about not giving yourself the impression that the learning curve is insurmountable, you can do it Perhaps I can, but with mercurial around I dont see why I need to. I think no one in their right mind claims git cannot be grokked. They question whether that effort is well spent given there are equally effective alternatives that people find simpler to use. Other than github I fail to see a compelling reason going for git apart for the linux kernel development workflow of course. Its not a bad tool but not quite the "you possibly cannot and should not do without it" that it is made out to be. I find this comment very telling https://news.ycombinator.com/item?id=8602259 https://news.ycombinator.com/item?id=8602259 I would rather do without all that.
    - nitrogen 12y ago
      I find this comment very telling https://news.ycombinator.com/item?id=8602259 https://news.ycombinator.com/item?id=8602259 I would rather do without all that. That comment goes out of its way to make things seem complicated. The different synonyms for things are confusing, and are evidence of the fact that Git has evolved over time rather than springing forth fully formed. That said, the staging area is one of the most useful features of Git, and if you don't want to use it, you can largely ignore it. The staging area allows me to make a few simple changes in the order that they occur to me, but add and commit them (using git add -p) in the order that makes the most sense for code review. Also: I highly recommend setting up shell aliases for the most commonly used commands, whether you use Git or anything else. "gco" is much faster to type than "git checkout", etc.
pjc50 12y ago
git commit and git checkout are fine. git pull and git push are where the problems start. as I got myself into tighter and tighter jams I suppose this is the thing; if you're happy to learn that way, fine. It's just that git is particularly prone to "I've trashed local state and lost work" / "I've just pushed a huge mess and will have to lose time cleaning it up, if that's even possible".
- click170 12y ago
  Those are valid, and very real concerns. Learning by mistake is one of the quickest ways to learn something though. Personally, to mitigate the possibility of losing my hard work to this problem, I started using git for personal projects and didn't use it for my important work until I was comfortable with it (eg had run into several problems, but resolved all of them). This also helped me understand Git well enough to teach it to my colleagues (and in teaching others, you learn even more yourself), and now that everyone on my team is comfortable with it we've switched to it almost exclusively.
- ibrahima 12y ago
  I love git, but even git checkout is asinine. It's fine for checking out a tag/branch/rev/treeish, but why on earth does it also revert files to their checked in state if given a path argument? I don't think git should be prone to trashing local state due to how it usually yells at you when it's about to do that, but then I've been working with a student this quarter who seems to do that every time I push something to github and she needs to pull. I think if the git community got together, did a usability study on how people actually use git, and renamed/split out commands into names that made sense, it would be a huge boon for general usability.
  - kazinator 12y ago
    > why on earth does it also revert files to their checked in state if given a path argument Simplification! :) "git checkout file" reverts a file from the index. If it doesn't exist in the index, then from HEAD. The problem is that you can make a typo, because branches, tags and files are all in the same namespace. Suppose you wanted to type "git checkout foob" which is a tag or branch, but instead you make a mistake and type "git checkout foom" which is the name of a file that happens to have unstaged changes. Oops! If "file" has unstaged changes, then "git checkout file" should rename it out of the way first to "file.#1#" or whatever. (Hello, look at CVS!)
parennoob 12y ago
> I dropped out of highschool and attended no postsecondary and I don't have any problems with Git. I started with the basics and read more as I got myself into tighter and tighter jams. I think you may be underestimating the wideness of audience that this may appeal to. I was thinking of introducing my rather older Dad who knows nothing about CS/programming to version control and plaintext. He is an accountant, and currently uses the "File_Copy_1.docx" method of version control, even for simple documents that could just be handled by plaintext. I would prefer that he avoid the confusion of git, where `git checkout [X]` can refer to [X] being a branch, commit, or file.. This new basic RCS may be good in that regard. I guess another option might be Legit (http://git-legit.org http://git-legit.org).
duaneb 12y ago
I would say, git isn't harder than any other distributed vcs. However, its tooling leaves a lot to be desired: its terminology is non-obvious and requires sifting through dense man pages (or dense reference books), it's hugely inconsistent (e.g. git remote rename vs git branch -m), and rebasing and merging can create confusing messes for users to sift through. DVCS is hard. Git is hard. They're hard for very different reasons.
- ynik 12y ago
  git is harder than other distributed vcs. With a centralised VCS, you have two 'version's of the file system: your local working copy, and the current branch in central repository. That leaves limited room for inconsistencies between the versions that might confuse the user / need conflict resolution. Logical versions = Number of working copies + Number of branches With a distributed VCS, you necessarily add a third 'version' (current branch in local repository). That's unavoidable. Logical versions = Number of working copies + Number of local branches (over all working copies) + Number of branches in central repository. But git is considerable worse: with git checkout working with a central repository, there's at least 5 versions involved, all of which may differ: working copy, index, local branch in local repo, remote branch in local repo, branch in remote repo. Different commands affect different 'versions', so it's easy for new users to get them into an inconsistent state, and pretty much impossible for them to recover: usually they can't identify the reason for their trouble because they do not distinguish between these 5 'versions' mentally. It's impossible to build good tooling on top of this mess, unless your tooling completely hides these extra 'versions' from the user by always keeping them consistent with some other 'version'. For example, a commit tool might use the stash only during the commit itself, so stash and local working copy are always kept consistent. Unless the user also uses the git command-line client... Of course, git is also hard due to the inconsistencies in the command line interface, but that's in addition to this fundamental unnecessarily complexity.
develop7 12y ago
Nah, it's not _that_ bad. Only way one may realize Git is hard is to compare it with other DVCSes, so avoiding that makes him confident enough to spread wishful speculations of it's something is wrong with people, not Git.

k-mcgrady 12y ago

I think git hard a small but steep learning curve. Lots of developers aren't used to using the command line anymore so git can seem 'scary'. Personally I gave up on git a couple of times before finally learning it but as a developer working by myself I also couldn't understand the need for version control (at the time) so giving up wasn't a big deal. I think once you give it a couple of hours of your time you can understand enough to use it in most situations. Plus the GUI tools (SourceTree for example) are quite good.

kazinator 12y ago

> I dropped out of highschool and attended no postsecondary and I don't have any problems with Git. Git problems arise when people want to do moderately sophisticated things, beyond just committing changes and viewing logs and diffs. > If git commit and git checkout are too complicated, If "If git commit and git checkout are too complicated" is your argument, then you aren't doing anything more sophisticated with git than what you learned from a svn to git migration tutorial in five minutes. People do more with version control than "commit and forget". If that's all you need, then what you really want is backup software that takes regular snapshots of your filesystem.

click170 12y ago
I think you may have misunderstood my comment, of course there is more to it then checkout and commit. Those are the basics, that's where you start. Then you get stuck somehow, and you read more. That's what I did at least. IMO It's about not giving yourself the impression that the learning curve is insurmountable, you can do it. Starting with the basics and growing up is, I thought, common knowledge for acquiring a new skill. I find when I get confused and flustered with git, every single time it's because I don't understand [yet] how I got into the current state. I've found that if I take a breath, put the problem aside and focus on figuring out how I got into that broken state, then the solution reveals itself -- not once have I ever lost code as a result of git confusion.
- deleted 12y ago
  [deleted]
- kazinator 12y ago
  I perfectly understand that there are hordes of programmers for whom messing around with git is far more interesting than the actual code they are working on. "Man, I just interactively rebased my last six changes so the commits are in a different order, and two of them were squashed into one! Boy, does that feel productive."
  - zBard 12y ago
    How is that in anyway a reply to what s/he wrote ? Even snark should have a purpose.
- srean 12y ago
  > It's about not giving yourself the impression that the learning curve is insurmountable, you can do it Perhaps I can, but with mercurial around I dont see why I need to. I think no one in their right mind claims git cannot be grokked. They question whether that effort is well spent given there are equally effective alternatives that people find simpler to use. Other than github I fail to see a compelling reason going for git apart for the linux kernel development workflow of course. Its not a bad tool but not quite the "you possibly cannot and should not do without it" that it is made out to be. I find this comment very telling https://news.ycombinator.com/item?id=8602259 https://news.ycombinator.com/item?id=8602259 I would rather do without all that.
  - nitrogen 12y ago
    I find this comment very telling https://news.ycombinator.com/item?id=8602259 https://news.ycombinator.com/item?id=8602259 I would rather do without all that. That comment goes out of its way to make things seem complicated. The different synonyms for things are confusing, and are evidence of the fact that Git has evolved over time rather than springing forth fully formed. That said, the staging area is one of the most useful features of Git, and if you don't want to use it, you can largely ignore it. The staging area allows me to make a few simple changes in the order that they occur to me, but add and commit them (using git add -p) in the order that makes the most sense for code review. Also: I highly recommend setting up shell aliases for the most commonly used commands, whether you use Git or anything else. "gco" is much faster to type than "git checkout", etc.

pjc50 12y ago

git commit and git checkout are fine. git pull and git push are where the problems start. as I got myself into tighter and tighter jams I suppose this is the thing; if you're happy to learn that way, fine. It's just that git is particularly prone to "I've trashed local state and lost work" / "I've just pushed a huge mess and will have to lose time cleaning it up, if that's even possible".

click170 12y ago
Those are valid, and very real concerns. Learning by mistake is one of the quickest ways to learn something though. Personally, to mitigate the possibility of losing my hard work to this problem, I started using git for personal projects and didn't use it for my important work until I was comfortable with it (eg had run into several problems, but resolved all of them). This also helped me understand Git well enough to teach it to my colleagues (and in teaching others, you learn even more yourself), and now that everyone on my team is comfortable with it we've switched to it almost exclusively.
ibrahima 12y ago
I love git, but even git checkout is asinine. It's fine for checking out a tag/branch/rev/treeish, but why on earth does it also revert files to their checked in state if given a path argument? I don't think git should be prone to trashing local state due to how it usually yells at you when it's about to do that, but then I've been working with a student this quarter who seems to do that every time I push something to github and she needs to pull. I think if the git community got together, did a usability study on how people actually use git, and renamed/split out commands into names that made sense, it would be a huge boon for general usability.
- kazinator 12y ago
  > why on earth does it also revert files to their checked in state if given a path argument Simplification! :) "git checkout file" reverts a file from the index. If it doesn't exist in the index, then from HEAD. The problem is that you can make a typo, because branches, tags and files are all in the same namespace. Suppose you wanted to type "git checkout foob" which is a tag or branch, but instead you make a mistake and type "git checkout foom" which is the name of a file that happens to have unstaged changes. Oops! If "file" has unstaged changes, then "git checkout file" should rename it out of the way first to "file.#1#" or whatever. (Hello, look at CVS!)

parennoob 12y ago

> I dropped out of highschool and attended no postsecondary and I don't have any problems with Git. I started with the basics and read more as I got myself into tighter and tighter jams. I think you may be underestimating the wideness of audience that this may appeal to. I was thinking of introducing my rather older Dad who knows nothing about CS/programming to version control and plaintext. He is an accountant, and currently uses the "File_Copy_1.docx" method of version control, even for simple documents that could just be handled by plaintext. I would prefer that he avoid the confusion of git, where `git checkout [X]` can refer to [X] being a branch, commit, or file.. This new basic RCS may be good in that regard. I guess another option might be Legit (http://git-legit.org http://git-legit.org).

duaneb 12y ago

I would say, git isn't harder than any other distributed vcs. However, its tooling leaves a lot to be desired: its terminology is non-obvious and requires sifting through dense man pages (or dense reference books), it's hugely inconsistent (e.g. git remote rename vs git branch -m), and rebasing and merging can create confusing messes for users to sift through. DVCS is hard. Git is hard. They're hard for very different reasons.

ynik 12y ago
git is harder than other distributed vcs. With a centralised VCS, you have two 'version's of the file system: your local working copy, and the current branch in central repository. That leaves limited room for inconsistencies between the versions that might confuse the user / need conflict resolution. Logical versions = Number of working copies + Number of branches With a distributed VCS, you necessarily add a third 'version' (current branch in local repository). That's unavoidable. Logical versions = Number of working copies + Number of local branches (over all working copies) + Number of branches in central repository. But git is considerable worse: with git checkout working with a central repository, there's at least 5 versions involved, all of which may differ: working copy, index, local branch in local repo, remote branch in local repo, branch in remote repo. Different commands affect different 'versions', so it's easy for new users to get them into an inconsistent state, and pretty much impossible for them to recover: usually they can't identify the reason for their trouble because they do not distinguish between these 5 'versions' mentally. It's impossible to build good tooling on top of this mess, unless your tooling completely hides these extra 'versions' from the user by always keeping them consistent with some other 'version'. For example, a commit tool might use the stash only during the commit itself, so stash and local working copy are always kept consistent. Unless the user also uses the git command-line client... Of course, git is also hard due to the inconsistencies in the command line interface, but that's in addition to this fundamental unnecessarily complexity.

develop7 12y ago

Nah, it's not _that_ bad. Only way one may realize Git is hard is to compare it with other DVCSes, so avoiding that makes him confident enough to spread wishful speculations of it's something is wrong with people, not Git.