from Hacker News

Why the Heck is Git so Hard?

by ludsan on 2/4/14, 12:10 AM with 63 comments

• by __david__ on 2/4/14, 1:25 AM

  > I still love the elegance of the Darcs model and command-line…

  I have mixed feelings about it now. Darcs was the first VCS I used and it was very well designed from a command line point of view. It's so simple and easy and it just made sense. The interface for adding hunks was just great and like nothing else that came before it.

  But—we (my partner on a project) recently just switched one of our earliest projects from Darcs to Git. It started in 2005 and we've been very happy with Darcs. But we'd been using Git a lot in the past few years and Darcs started seeming a little simplistic. We were really hesitant because it had been working so well for the past years and why change something that isn't obviously broken?

  We decided to just do the Git switch and it because clear after just a couple days of working with Git that it was a much better experience overall. Having easy easy feature branches and "git stash" and "git rebase" made our lives so much better and our moods so much happier that we cursed ourselves for not switching years ago.

  Git even copied the Darcs hunk interface with their "add -p" and "checkout -p" options, which I use constantly.

  Since I became proficient at Git, nothing else looks good any more (even the VCSes I used to love).

• by elviejo on 2/4/14, 1:47 AM

  I agree. Just based on the number of tutorials and posts about how Git is difficult / hard / weird

  Seems to me that Git is more complicated than it should be.

  I mean code repository as a software developer is an essential tool it should be as intuitive to use as a text editor.

  PS: Also the common answers to "Git is complicated" are symptom to me that is harder than it should be 1. "Git is not version control is an application framework" well since it only has a version control build into it I say thay are the same.

  2. "Git is difficult but it enables you do to really powerful stuff" Here I quote Kay: 'Simple things should be simple, complex things should be possible.' Seems to me that git took the approach complex things are complex and simple things are complex too!

  3. "You just don't understand Git's model" Well many programmers barely understand what a compiler does yet they are capable of writing software.

  4. "You just haven't invested the time it takes to master git" I have seen posts from developers working with Git that still can only do the most basic stuff.

  Those are the same excuses used for previous technologies just replace git with: Java threads (before Go, Erlang) OOP (before Java, Smalltalk) Functional Programming (before haskell, F#)

  In each case when the tool was correct the paradigm became obvious.

• by SeanLuke on 2/4/14, 2:27 AM

  Perhaps the question should not be why is Git so hard compared to SVN. A better question is, why is Git so hard compared to Mercurial. For me the problem is not the complexity of the model -- the value prospect of a DVCS is clear. The problem is the complexity of the interface.

• by giulianob on 2/4/14, 2:14 AM

  I use both Mercurial and Git. Mercurial is just as powerful but does a much better job at hiding the underlying model and doesn't make it as easy to shoot yourself in the foot. You can see a comparison of the concepts here: http://mercurial.selenic.com/wiki/GitConcepts (maybe a little biased but I think it does a good job)

• by gkoberger on 2/4/14, 1:14 AM

  It is hard... but it also lets you do some insane stuff (patch mode, reflog, cheap branching, pushing to each other, not being centralized, etc).

  That being said, for beginners, GitHub's app (albeit GitHub-centric) breaks down the most common use cases and turns them into buttons. It's probably a good place to start.

• by hcarvalhoalves on 2/4/14, 2:24 AM

  98% of the WTFs in Git are attributable to the poor command line interface, with badly named commands and forgettable option switches; the underlying workflow is simple. It's only palatable after you make some aliases.

• by bhrgunatha on 2/4/14, 1:43 AM

  I expect most people know about this already, but the interactive git cheatsheet by NDP Software is excellent.

  http://ndpsoftware.com/git-cheatsheet.html

• by jjoe on 2/4/14, 2:05 AM

  Because it was created by Linus for Linux, a systems kernel. Very few people need to interact with a kernel. And the ones who do are so technically advanced they put up with the steep curve inherent to using Git. The fact that Git has gained popularity outside of Linux kernel development is secondary.

• by caitp on 2/4/14, 2:08 AM

  Git provides some amazing tools in a very accessible way:

    1) A great way to find regressions which is easy to automate (bisect)
    2) light-weight branches
    3) nice tools for dealing with patches (am, format-patch)
    4) rebase (squash, amend, fix bitrot)
    5) Super-simple submodules (compare this with gclient DEPS to get around SVN
       limitations!)
  

  Not to mention the main point of Git, the distributed nature, and the ease of moving code between two repositories.

  These basics are easy to learn, not demanding at all, and just feel good to use. I have trouble comprehending when people say it's difficult, especially compared to things like Mercurial (and the mq extension), or SVN.

• by stephen_g on 2/4/14, 3:34 AM

  Maybe it was just that I happened on some good intro tutorials or something, but I found Git ridiculously easy to pick up and have never really had any problems since.

  I was using SVN for my job, which was crap (big code base, everything was super sluggish and branching and merging was an absolute nightmare). I tried Git on a little personal project and immediately it felt far better. We switched at work about a year later (it took days to import > 8 years of SVN history).

  The CLI has some gotchas, but really it didn't take me long at all to work that out.

  And say what you want about the staging area, but I absolutely love it. You can skip it if you want (git commit -a) but I think it's awesome and super-useful.

• by IgorPartola on 2/4/14, 2:01 AM

  Minor point: the stash, the local changes, and the staged changes are all very simple to grasp. In fact, you don't have to use the stash at all and you could even forego the staging area since you can just get git to commit unstaffed files directly. Sure, there is a reason those things exist, but if you are still in SVN world and are using git for the first time, these are not the places likely to trip you up. What you are likely to get confused by is things like rebasing, and the fact that your local repo can be modal, such as when there is a merge conflict while rebasing.

• by djtriptych on 2/4/14, 1:57 AM

  git is NOT hard iff you understand the data model. Don't use it until you understand the data model.

• by cousin_it on 2/4/14, 1:56 AM

  A couple obvious questions:

  - Is it possible to design a Git-like VCS with only two or three "places" instead of five?

  - What would be the downsides of such a system?

• by na85 on 2/4/14, 3:07 AM

  My main beef with git is that the documentation seems written not for someone learning git for the first time, but for someone who wants to develop for git and is already intimately familiar with git and all its nuances. It's dense and obscure, and more often than not it quite simply doesn't answer my questions.

  To be blunt, git seems good but the documentation blows.

• by fideloper on 2/4/14, 2:21 AM

  Git is hard until you learn more about it. Just like programming. And using servers. And everything we do that makes us worth hiring.

• by jaybuff on 2/4/14, 2:38 AM

  The best book on git is only 30 pages long. It's called git from the bottom up and it describes the architecture of git, which makes understanding it much simpler than studying command line options.

  http://ftp.newartisans.com/pub/git.from.bottom.up.pdf

• by hannibalhorn on 2/4/14, 2:23 AM

  I still think the absolute best way to learn git is to watch the talk Linus gave at Google some years back - http://www.youtube.com/watch?v=4XpnKHJAok8 - just understanding the underlying concepts makes the rest of it easy to grasp.

• by delinquentme on 2/4/14, 2:19 AM

  Its not. Work Git in a simple workflow. Start with adding, amending, rebasing and stashing. Additionally incorporate it into your workflow.

• by tks2103 on 2/4/14, 2:08 AM

  Betteridge's law of headlines states: "Any headline which ends in a question mark can be answered by the word no."

  You have to modify the law a bit with this article but you get something like "Git is not hard". That is the answer to this article.

• by joemaller1 on 2/4/14, 2:09 AM

  When did blogspot break the back button?

• by jaunkst on 2/4/14, 2:34 AM

  Is it really hard? Anybody can use git.

• by xyclos on 2/6/14, 2:09 AM

  git is easy.

• by wcummings on 2/4/14, 1:18 AM

  Honestly, it's a lot easier than SVN if you're doing anything even moderately complicated. I think there's a bias from people who learned SVN first.