What I Hate About Git - <AUTHOR> https://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/ <comment><USER4> I found the #1 reason to be incredibly ironic:

> _The information model is complicated – and you need to know all of it. As a > point of reference, consider Subversion: you have files, a working > directory, a repository, versions, branches, and tags. That's pretty much > everything you need to know._

SVN's model is both simpler than stated here, but also much more complex to reason about. First of all, svn doesn't have branches or tags, it just has directories with cheap copy—tags and branches are just directories. The repository itself is also watered down pretty severely because the actual project directory is just nested in there somewhere with no formal locus. This idea of "everything is a directory" sounds simple, but in practice it's a architectural dead-end. The most obvious implication is that merging in svn will always be fraught with peril because a branch isn't a first-class citizen.

I used svn (and cvs before it) for much longer than git, and yet I never felt I had any clue what svn was doing under the hood, and the experiences I had over time instilled a fear of attempting to stray off the well-worn path of the most basic commands.

Although the learning curve was steep, and the CLI quite confusing, the git information model is actually much easier to grok because the primitives make more sense. After 6 months using git, I had a firmer grasp of the internals than I did after 10 years of cvs and svn. The idiosyncrasies of the UI don't really bother me because they are just superficial flaws that are easily memorized or looked up. The fact that I have the confidence to slice and dice commits to any history I can envision, with or without a network connection and remote repo, and do so with the reasonable confidence that I will never lose anything (reflog) make git the best VCS I can imagine.

<comment><USER5> I fully agree. SVN traditionally had some things that simply didn't work, often related to file renames.

I remember trying to rename a file after 'svn add' but before 'svn commit', and it simply didn't work. Maybe that's fixed now, don't know. Or merging stuff when a file was renamed in one branch and changed in the other.

During my several years of SVN usage I have regularly driven SVN checkouts against a wall, where I didn't manage to recover them into a usable state, not any combinations of revert, update or other commands. This has never happened to me with git.

</comment></comment><comment><USER6> Number 1-5 are mostly "I don't want to learn new things", so I'll ignore them. Do you remember when you learned source control for the first time? I don't, it was too long ago. Just like you have to learn SVN if you've never used source control before, you have to learn Git if you've never used distributed source control before.

* "Unsafe version control", and then gives examples using -f or +<refspec>, both of which advertise their destructive nature. Yes, you can also go in with SVN and obliterate history too, using svnadmin dump and svnadmin load. Git's reflog will have your back when you make mistakes, as long as the mistakes don't get too old.

* "Power for the maintainer, at the expense of the contributor" Yes, most people write code on one branch for a long period of time. Git does this just fine.

* "Burden of VCS maintainance pushed to contributors" First of all, nobody says that contributors have to merge. That is a decision that each project makes. Plenty of projects have the lead developers merging in everyone else's work. Second, the reason this is even an issue is because merging is such a pain in SVN that most people don't want to do it.

* "Git history is a bunch of lies" Again, this is up to the individual project. Some developers like to work on six different things at the same time, and then they go back and rewrite history so that their six changes end up as six commits. The difference with SVN, is that these same developers would simply avoid committing until they're done with all six changes. Some projects expect rebased patches, some prefer proper merges. Worse, the author says that "filtering" should solve this problem, but doesn't propose how such a filter would work.

* Complexity of simple tasks: Let's try not to artificially inflate the complexity of the Git tasks. For example, the Git examples assume no commit access, whereas the SVN examples assume direct commit access. If you don't have commit access to an SVN project, how do you do it? You either use git-svn and mail them a patch, or you use svn and mail them a patch.

A recurring complaint seems to be that "git add" is not the same as "svn add". I don't see why it would be. It's not the same as "ssh-add" or "useradd" either.

<comment><USER7> 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> (gitref.org is maintained by GitHub)

<comment><USER8> > 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.

<comment><USER9> 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.

<comment><USER10> > 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?)

<comment><USER9> 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.

<comment><USER11> You can configure `git push` to push just the current branch to its configured remote, by setting 'push.default' to 'upstream'.

`git config --global push.default upstream`

The relevant docs (droplr'd, since you can't anchor-link into the online manpages): <http://d.pr/Rlqn>

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> Have people done hallway usability testing on git?

i.e. just take a smart undergrad CS major and record their screen (& audio) while they try to figure out how to use it. I think this would definitely turn up some tasks within it that are way harder than they need to be. Do people really feel confident that learning git is a smooth process, not involving a lot of swearing?

The answer you mostly hear when complaining about programming tools is that you need to toughen up - yet startups are founded on the idea of not doing this to their clients. Making processes super easy for clients is a good thing, and we should gather information, find the common problem spots, and fix them for our own tools! We shouldn't just keep insisting that the customer (programmers) needs to toughen up and learn (as the default answer, anyway; some things really are hard)

Why isn't there user feedback tool for man pages, where it asks "Was this information helpful to you?" every time you use a man page? I bet the success rate would be pretty low.

In general why isn't there any information about which man pages are good and which are terrible? They just seem frozen in time. Compared to the analytics startups get about their customers, info about man pages is nonexistent. Yet there are probably ones out there which would be rated "useless" 99% of the time, and have been for 10+ years with no change.

<comment><USER13> I think you bring up some good points of open source projects vs. commercial ones. In open source projects, most of the time when seeing critical feedback by users you see those "it's open source, just change it the way you want" comments. No one makes money, therefore no one depends on users being happy about the software. That's why B2B is so attractive: Your users actually WANT to pay you such that you are dependent on their happiness.

Maybe we should invent a new model that combines open source with paid incentives for user desired changes. Let's say User A uses Gimp, sees something that could be simplified or added. He can't program it himself but what he can do is describing the feature he wants, possibly with screenshots or even an interface prototype. He then auctions this on a marketplace website. Other users can upvote or even chip in to A's auction such that the probability of a good developer implementing it rises. Developers have their profile with reputation, possibly linked with their stackoverflow reputation. The change gets implemented within a branch of gimp, installable by anyone using a modified package manager. If the maintainers of gimp like the change, they can merge it in such that everyone profits - the number of user downloads being a good indicator that the change is desired.

</comment></comment><comment><USER14> Amen! I've felt like this for so long.

Ignoring the unnecessary parts about GitHub, he hits the nail right on the head with:

> _Git doesn't so much have a leaky abstraction as no abstraction. There is > essentially no distinction between implementation detail and user interface. > ...Its weakness is the complexity of simple tasks._

I swear, someone needs to invent a Git-wizard program. Interactive with a wizard-like interface, it will walk you through all the common kinds of tasks, even if they're fairly advanced, explaining all the ramifications along the way.

I haven't seen any programs like this -- all the GUI interfaces to git basically just translate to command-line commands, instead of trying to help you intelligently manage your workflow.

I don't think it would be easy to write a wizard interface like this -- it's a UI designer's worst nightmare -- but it would certainly help.

<comment><USER15> > I swear, someone needs to invent a Git-wizard program. Interactive with a > wizard-like interface, it will walk you through all the common kinds of > tasks, even if they're fairly advanced, explaining all the ramifications > along the way.

Sounds like a great idea for making _one type of workflow_ easy. The great part about Git not having an abstraction is that it supports almost any workflow. You can choose what flow is right for your project.

Which is, by the way, why the documentation is not task-oriented, it's data- model oriented. The same command might be used for two completely different tasks in two different processes.

Other tools that aim to make the basics for committing easy do so at the expense of implicitly supporting only certain workflows. Think of something like Perforce. You don't _enforce_ your process with Perforce, you _choose_ your process so that it will work with Perforce.

<comment><USER14> That's why I said it's a UI designer's worst nightmare.

Because there are a lot of different kinds of workflows, and I don't even know how you'd begin to organize them. I mean, maybe it's not even possible.

It would just be nice if it were more possible to "ease into" Git, rather than feel like you have to go through the equivalent of a college semester learning it.

<comment><USER16> > That's why I said it's a UI designer's worst nightmare.

This is the point where I think it's appropriate to link another front page article: <http://news.ycombinator.com/item?id=4338845>

I've learned Git about the same way I've learned *nix systems and programming languages in general: piecemeal, a step at a time, on a largely need-to-know basis. It's been 4 years now and I feel like a complete novice, but I rarely need to do anything other than (1) synching local with remote repo, (2) committing a change, and (3) using a feature branch.

</comment></comment></comment></comment><comment><USER17> Git is far from perfect. But, there's roughly half bullshit, half "yes but is it really an issue?" things here to me.

Things like detailing the _github_ process and blaming _git_ just does not work for example.

Blaming additional git features that svn simply does not have.. is also nonsense to me.

Finally, you CAN rewrite history in svn, its just extremely painful. In git it's not and.. its a good thing. I prefer USEABLE history than trashy commits. And don't tell me its about having proper devs making commits. As pointed out, you get external commits in git. You can't control them without refusing them and then what? In svn you don't _even_ have the possibility to refuse them.

Don't get me started on how svn is way more about the maintainer due to this...

<comment><USER4> > _I prefer USEABLE history than trashy commits._

Yeah the other day I got into an extended debate about rebasing with another dev who just didn't get this. He maintained that it should not be possible to modify history because it all may be relevant later. I rebutted with a question: do you want a commit every time you type a character in your text editor? Version control is just another tool for code craftsmanship. You should strive to make your commits as atomic and well-described as humanly possible. git-add -i and git-rebase -i are tools that allow you to approach a more perfect history.

<comment><USER18> > I rebutted with a question: do you want a commit every time you type a > character in your text editor?

I don't get it. I want a commit every time I say I want a commit, not upon arbitrary criteria the software decides for me. And I want that commit to be irrevocably and permanently immutable, because I said I wanted it and because it might be relevant later. What am I missing?

<comment><USER19> When you want a commit, you tell git to commit and it will commit.

When you don't want to revoke or mutate a commit ("irrevocably and permanently immutable"), you don't tell git to revoke or mutate the commit and it won't revoke or mutate the commit.

When you fucked up history and you want to change it, there are some simple git commands to do this and some very, very tedious svnadmin commands to do this.

Some of us fuck up history and want to change it. Some of us don't. Git serves both of us well. Subversion only serves one of us well. A lot of the time we have to use the same version control system, because we want to collaborate.

<comment><USER6> Additionally, if I have admin access to the SVN repository and rewrite history, how would you ever find out unless I told you about it?

In that sense Git has stronger support for immutable commits, since rewriting published history will actually cause everyone downstream to stand up and notice.

</comment></comment></comment></comment></comment><comment><USER20> Excellent article, this reflects much of my personal experience working with git in the last year.

Our whole department (>100 people) switched as part of a move towards decoupled development/continuous integration, we used perforce before. Luckily there were three people with excellent git knowledge who could answer all questions so this helped a lot.

However, I find myself relying on stackoverflow/google for some not-so-common small use cases where a glance at the manual just doesn't help (find all changes in local branch not in upstream branch x?). Also, the git commands and their options are sometimes not very logical as the article mentions (i.e. git show vs. git blame, the first needs the syntax "branch:file", the second "branch file", why? Small things like that take away from the beauty)

git is powerful and I prefer it to perforce for it's possibilities, but I think tools like mercurial are a better DVCS which just didn't have enough hype at the right time.

</comment><comment><USER21> This generally sums up why I prefer Mercurial. It provides all the benefits of a distributed VCS, but with less of the complexity, at the expense of some (usually unneeded, at least for me) flexibility.

<comment><USER22> Given that "everyone" knows git, and essentially no one uses hg, I think saying it involves "less complexity" is very much missing the forest for the trees.

<comment><USER23> No one except for the entire Python development team. And me.

<comment><USER24> And all of Mozilla. And Oracle's Java dev team.

Windows support was a big deciding factor.

<comment><USER25> And Adium and pypy and Sphinx and gevent and almost every project on bitbucket. But _apart_ from them, "essentially no one" uses mercurial! :P

</comment></comment></comment></comment></comment><comment><USER26> "If the power of Git is sophisticated branching and merging, then its weakness is the complexity of simple tasks."

The power of Git is its distributed nature and the fact that you can maintain local commits. When you have a single remote repository that everyone commits to, then sure, it's really easy to do things (have fun maintaining the ACL and merging any changes contributed by anyone outside the committer list via patch). If you think "it's really easy to branch" is the primary reason to use Git, you're using it wrong.

<comment><USER27> > The power of Git is its distributed nature and the fact that you can > maintain local commits.

that's actually the power of any DVCS.

<comment><USER26> Yes, that was my point. He's comparing a VCS with a DVCS and then complaining that the "D" adds overhead.

</comment></comment></comment><comment><USER28> I think the biggest problem I have with git is that I don't understand how people can't get it. (That's assuming they understand DVCS, but don't get git. Not understanding DVCS is unsurprising.) It's like when my nonprogrammer friends who took CS101 didn't understand for loops. What?! It's just applying a concept you already understand.

It's unfortunate that git re-uses some verbs from cvs/svn with different meanings, but is that really such a big hurdle?

And I'm always surprised to hear complaints about git's user interface. I find the command-line interface far friendlier than others: auto-paging, colorized output, text hints of what I should do next, and fantastic tools (like bisect) in the same package.

And looking through my bash history, most of my commands don't use any options (the biggest exception is git commit). Possibly this is because I do most of my git interaction through vim-fugitive (and I have aliases for commonly-used complex commands). But I think it makes more sense to have a smaller set of commands that are logically organized (rebase mangles your history, reset re- aligns based on your history, ...) than a single command for every function.

</comment><comment><USER29> Defenses of git sound remarkably like defenses of C++ syntax and feature design. In fact, I'd argue they are similarly written by people who are overly proud that they are smart enough to figure out some convoluted and arbitrary complexity, but not wise enough to realize that level complexity is unnecessary.

<comment><USER30> Your comment sums the issue amazingly well. Well you look at the user interface it is clearly evident that these guys had forgotten that not everyone is a kernel hacker. And it seems as if they tried their best to make everyone else feel like an idiot because they don't have the time or want to understand the arbitrary decisions they made or are simply not smart enough to understand it.

</comment></comment><comment><USER31> I'm all for trying to find ways to improve Git's learning curve, especially for non-technical users.

That said, if you're calling yourself an engineer, you've worked at a Git shop for over a month, and you're still complaining about how "hard" it is? I have absolutely zero sympathy. You're being paid twice the national average to do a job that's supposed to be mentally difficult. You use version control every day. Stop whining, learn to use your tools correctly, and stop subjecting the rest of us to your crappy, disorganized commits.

</comment><comment><USER32> Ever try to commpile git statically?

Git makes you believe it's lots of small little utilities that work together.

Far from it. Git relies on Perl or another scripting language, not to mention it's reliance on curl.

You cannot run Git without these other sizeable programs.

I can make static binaries of RCS, CVS and SVN no problem. CVS uses SSH. No silly SSL and the certificate mess. I value the simplicity.

Mercurial (which seems to be a favourite among connoisseurs of versioning systems) relies on a Python intepreter, but it's reasonably contained to a single Python script; no installation required. You point Python at hg and it works.

Of course, it's been said that most of the time people who ramble on and on about these systems and their esoteric features do not need the advanced features. They rarely use them, except as points in a debate over which versioning system is "the best".

<comment><USER33> This is, by far, the strangest git complaint that I have ever heard. What are you trying to do, ship embedded devices with git on them?

<comment><USER34> "avoid holding it that way"?

<comment><USER33> Honestly? Yes. Sometimes that is just the only reasonable response.

<comment><USER34> is there a complete list of ways I should avoid to hold git?

</comment></comment></comment></comment></comment><comment><USER35> I love git and prefer it to svn, but he's right. It succeeds in power and usefulness, but utterly fails in the complexity department. Someday, someone who understands the virtue of simplicity and can control their "how dare you insult my favorite tool" response will take this criticism to heart and rework git (or at least, re-porcelain it).

<comment><USER6> I think the re-porcelain option is really the most viable option here, for those who complain about git's arcane invocation. So many Git commands actually do two or three different things depending on invocation.

</comment></comment><comment><USER36> Sounds like someone's just discovered how different DVCS are to centralized VCS.

Still, tools like Tower, Smartgit and Github for Windows, especially Tower, make interface to Git less painful.

With time, the interfaces to Git workflows can only improve, whereas what can you do with SVN?

That said, he may have a point about (branch &) merge message management in Git. Perhaps this can be improved closer to git with git extensions, e.g. implementing some sort of ranking and filtration system. Related to that is users should not really have to change the structure of the VCS itself just to filter messages.

</comment><comment><USER37> I have to admit, it confuses the heck out of me. I am always in fear of destroying code because the documentation part is spot-on. I read and reread, and still feel like I am working on a best guess interpretation.

<comment><USER38> Using man files and in-built help is probably always going to only give you half the story. Have you considered reading the Pro Git book? <http://git- scm.com/book>

</comment></comment><comment><USER39> I can't count the number of times I've googled for simple commands like "how do I revert an uncommited file to its original state"?

        hg revert bla.txt
        git ???

... and I would still have to google for it (it's something with HEAD iirc). Its usability is atrociously bad and I don't want to spend time learning some badly designed cli interface when I can focus on more important things and use tools that make my life easier, not harder.

<comment><USER40> git checkout bla.txt ? I'm not sure how I get how that's harder. I'll throw one back, how do I do the equivalent of git stash and git cherry-pick in hg?

<comment><USER39> Ah, good to know. Everytime I've googled this it was something about reset --hard (or --soft) and HEAD or ^HEAD or whatever else.

git stash is hg shelve. Don't know about cherry picking (I've never needed it).

Anyways, the argument I'm making is not "which tool is more powerful" but "which one is easier to use while being powerful _enough_ ". For me that is Mercurial, hands down.

<comment><USER40> cherry-picking is amazing for the "oops I did that fix on master instead of the 2.x branch". git cherry-pick <hash>. done.

<comment><USER39> Just for the record, the transplant extension [1] seems to be how you do cherry picking in Mercurial.

[1] <http://mercurial.selenic.com/wiki/TransplantExtension>

<comment><USER25> Transplant is a great extension and very useful in a pickle.

</comment></comment></comment></comment></comment></comment><comment><USER41> I can say this: I've used both Mercurial and Git professionally, and for distributed version control, I found Mercurial _much_ simpler to use.

</comment><comment><USER42> My issue with git is the defaults. Generally the defaults and behaviour are geared towards large projects. It is absolutely correct in that sense - <USER2> don't want hundreds or thousands of contributors messing things up. An additional simple example is that push doesn't send tags.

But generally you want the opposite defaults for small projects/number of users. For example you do want tags pushed by default so every sees them. This places a large learning curve on the small scale projects and users. Remember that most users will be perpetual intermediates.

My analogy is that git is like a sharp knife. In the hands of an expert it can produce art, but in the hands of others we get blood. Some of the responses here are marvelling at the sharpness and what can be done with it, but are missing the point that others end up bloody!

<comment><USER4> Aren't you more likely to cut yourself with a dull knife though?</strained- analogy>

<comment><USER43> I think you're more likely to feel pain with a dull edge, but a sharp edge cuts easier.

<comment><USER4> The point is it slips off the tomato and cuts your finger.

</comment></comment></comment></comment><comment><USER44> I find his complaint about git's lack of abstraction strange. Yes, git's syntax could definitely be more consistent, but I can't think of how you could abstract away very much of git without quickly losing power.

On the other hand, one of the things I hated most about svn is that it doesn't abstract away the remote repository details at all. To do something as simple as check out a branch you have to type in the full absolute url to your repository, since a branch is basically a different folder higher up in the hierarchy. Talk about a leaky abstraction.

The abstraction between version control tools and the remote server(s) you back everything up on and the power of git's underlying model are both such big wins that I really can't get too worked up about the syntax.

</comment><comment><USER45> Yet another anti-git rant which will merely bounce off the deflector shields of the git faithful. I doubt anything will change in terms of git usability and misfeatures until someone proves that there's a better way to do it by building an alternative that's all around better than git. But that raises the question of why one would continue to use git at that point.

<comment><USER46> Using Mercurial daily, I don't understand why it isn't widely viewed as the alternative to git that you mention. It seems to avoid some of the pain-points the OP lists.

The idea that there are "git faithful" is a sign of how immature (in every sense) the software development field is. Masochism and complexity-worship seem to blight our field(not necessarily referring to git, which I'm not qualified to comment on)

</comment></comment><comment><USER47> Git is _awesome_. Once you "Get it", there really is no big problem. Sure you may have to look up some syntax occasionally and make an alias or two for your common uses, but really, it's no big deal.

And the benefits are compelling. Enjoy the amazing power of committing early, and committing often. Being able to revert to "10 minutes ago" is so freeing when trying out a refactoring idea. And being able to "uncommit" the last X commits to recommit them in a different order and with cleaned up messages and structure before sharing with colleagues... amazing.

All the quibbles about syntax really miss the point and the power of Git.

</comment><comment><USER48> He mentions three ways to irrevocably lose data. Is that really accurate? I would think old refs are still present in the repo and accessible from .git/logs, but I don't have any experience actually collaborating with git.

<comment><USER49> Rebasing isn't really destructive. Try it: open `gitk --all`, do a rebase -i and squash all the commits together, then switch back to gitk and refresh. You'll see all the old commits still in the database, but the HEAD and master branches point at the new commits. Totally not destructive, but it does take a bit of knowledge to undo the change.

Git maintains what's called a "reflog" to help with this. It's a record of every place that every ref has ever pointed in your repository. Try it: `git reflog master`. You can even see when you did pulls, and what they merged in.

The only truly destructive thing you can do to your git database is `git gc`.

<comment><USER29> > The only truly destructive thing you can do to your git database is `git > gc`.

And of course we should expect garbage collection to be destructive of information that is not garbage?

Didn't know that? Just read the man page. Whoops, it doesn't actually mention that, but it does mention that it may happen automatically at times.

So only clever people like you know archaic undocumented side effects of git's inscrutable design, except nobody ever really knows the full story because there is so much unnecessary crud to learn in addition. Clearly more can be destructive than gc if gc can be executed by other commands and triggers by repository state.

<comment><USER50> git gc be default does only prune things older than 2 weeks so to lose your recently lost commits you would have to explicitly give a prune which is today.

I do not think one can do this accidentally:

git gc --prune=2012-08-05

</comment></comment></comment></comment><comment><USER51> Allow me to add one to the list:

11\. Completely different concepts for the same commands as other SCM systems.

Case in point: Checkout. In every other system prior to git, going as far back as CVS in 1986, checkout meant grab a remote repo and copy it locally.

In git, it suddenly means to switch branches in a repo you already have. The real "checkout" was renamed to "clone".

Why not use something like "switch" instead?

That's nearly 20 years of muscle memory everyone needed to relearn because.. why?

Git add and SVN add do completely different things as well.

Was it simply not thought of that people who use git would be switching from another system at the time, very likely to be either svn or hg?

<comment><USER38> Yeah, but you could also argue that it doesn't make as much sense in git to call cloning a repository "checkout". Because you are cloning the repository to your very own _local_ repository, then you make your changes from that repository and then you push back to the original repository, which is a _remote_ repository.

Essentially, a checkout in git is to checkout files from a particular branch into the current working directory. And that branch is actually in the index, which I would really call the repository - so actually you are indeed "checking out" files from the repository. Once you make your changes, you commit them right back into the index.

</comment></comment><comment><USER52> Dear OP,

If you're still using git from time to time and get frustrated please feel free to ping @gitdoctor on twitter. It's an account I run to try and help people use git right when they need that help.

Thanks and good luck!

</comment><comment><USER53> You don't need github to make pull requests:

[http://www.kernel.org/pub/software/scm/git/docs/git- request-...](http://www.kernel.org/pub/software/scm/git/docs/git-request- pull.html)

<comment><USER54> You dont need github for anything, period. So its very strange that it is mentioned at all when comparing it to other version control systems.

<comment><USER55> Let me translate:

3 things I hate about (the culture surrounding) git(hub):

1,3,4,5 - I'm expected to understand the information model.

2 - The CLI is inconsistent.

6,7,8,9,10 - I'm expected to work harder so that life is easier for the maintainer.

</comment></comment></comment><comment><USER56> Having used both git and hg, I very strongly agree. I learned hg first. Hg took less time to master than git took learn the basics of. The syntax of git is incredibly cumbersome in comparison -- I type a lot more. It's the standard, but relative to hg, not a very good standard.

</comment><comment><USER57> git is only complicated because it lets you do everything you may possibly want to do, often a superset of what you actually want to do.

If you want svn-like commands, you can borrow someone's scripts or use a shiny GUI. I don't want svn-like commands because centralized version control is obnoxious.

Don't complain because it's hard. Programming is hard, math is hard, and if you know how languages, data structures, and algorithms work, git is actually pretty easy in comparison.

<comment><USER25> I disagree. git is complicated because it does not have defaults, command line intelligence and does not have a consistent user interface. It forces you to constantly be repeating yourself and to learn a lot of detailed incantations (Like mentioning HEAD and origin and master over and over.)

I say to you, don't complain that people are complaining. People are complaining for a reason.

Have you tried some of the other DVCSes? Mercurial, or Darcs, or bazaar? Gits problem is not the problem domain, nor the backend. It's the user interface. That's the hard bit.

</comment></comment><comment><USER58> Git doesn't seem to have been developed with ease of use in mind. I've found that it's very powerful, and that most things that you want to do with it are possible, but not always as easy as it could be.

I'm working on a collaborative project with several inexperienced developers using various editors and operating systems, and dealing with line endings has been a serious time sink. The first step was "* text=auto" in a .gitattributes file to override everyone's local settings, as some had used custom settings when they installed Git.

Apparently the developers of Git decided to not support \r as a line ending, which ended up causing headaches for us because some legacy programs still use it. Several times, someone committed changes to a file where \r\n line endings had been replaced with just \r, for whatever reason. To Git, they had just deleted the entire file and replaced it with one long line. This frequently resulted in edit conflicts where it was very difficult to tell what had actually been changed.

The solution ended up being a filter:

        clean = LC_CTYPE=C awk '{printf(\"%s\\n\", $0)}' | LC_CTYPE=C tr '\\r' '\\n'

...which everyone now has to duplicate in each of their local .git/config on every copy of the repository they use. Coming up with that little bit of command-line wizardry, and getting everyone to install it (and making sure it worked on Windows/OS X) ended up wasting the better part of a day to accomplish what seems like a relatively simple task.

So, in the end it was possible, but the process could've been much friendlier.

I will say, though, that git bash is absolutely amazing and blows Cygwin out of the water for ease of use.

<comment><USER59> > ...which everyone now has to duplicate in each of their local .git/config on > every copy of the repository they use.

You can use git in your .git. Add those hooks to the repository. Every dev will get them automatically on checkout. No one should have to install anything. (Well, aside from Awk.)

<comment><USER58> That never occurred to me. Thanks for the suggestion.

</comment></comment></comment><comment><USER60> I'm going to be contrarian and say that he's mostly right for all of them. SVN was simpler, git is more complex. SVN did some things well that git does not so well.

But this all misses the point. Git is many many times more powerful than SVN. And that complexity is really useful, even for relatively small projects. You can learn Git's complexity, removing many of SVN's advantages. But you can never get Git's power into SVN.

</comment><comment><USER40> I've been using git for several years on multiple projects with teams of various sizes (admittedly none larger than 10, though I avoid projects of that size for a multitude of reasons) and have loved it a lot. Especially compared to the merge headaches of svn. Or cvs. And mercurial just gets in my way more often than not. git stash I awesome

</comment><comment> why-el > The fundamental promise of any version control system is this: "Once you put > your precious source code in here, it's safe. You can make any changes you > like, and you can always get it back. Git breaks this promise".

Right there. I don't know who made this promise, but it's not what Git is supposed to preserve. Git is distributable is it not?

</comment><comment><USER61> Number 10 is a total apples-to-oranges comparison. For an apples-to-apples comparison, the question is, do you want to give your contributors write access to your master repo? (and deal with the consequences)

If contributors have write access, then Git is almost as easy. There's just one more command ("git push") compared to SVN.

If contributors don't have write access, then there's no easy way to do this with SVN. Most places that I've seen will either have users submit .patch files via email, or put their changes in SVN branches (ugh). Or, they convince themselves that they'd rather just give contributors write access. Either way, Git has many handy ways to solve this problem (Github pull requests are just one of those ways), and it definitely wins on this front.

</comment><comment><USER62> I tend to summarize it like this:

Git is built by people smarter than you for people smarter than you. Deal with it.

Now, seriously, Git is a) immensely flexible and b) born out of the needs of Linux kernel developers (or, more specifically, Linus' needs). I would expect it to be optimized for that case.

<comment><USER63> There sure is a lot of evangelizing for it if it's only intended for the 1% elite developer.

<comment> j-kidd That's exactly the problem, i.e. those people who endlessly promoting git so that they can be seen as elite developer. Their favorite past time is to share their "get it" stories with the rest of the world.

Not unlike the "Are You There God? It's Me, Jesus" episode of South Park.

<comment><USER62> Git is a tool. You use it if it solves your problem. You can certainly use it the same way you'd use Subversion and it's not any harder - it'll just behave as a version control system that can buffer commits offline with two "levels" of commit - local and remote.

If you want to use the more complicated stuff, then there is no way to avoid learning the more complicated ideas.

There is a lot I don't understand about Git, but, as far as my usage patterns have gone, I'm very satisfied.

<comment> j-kidd > You can certainly use it the same way you'd use Subversion and it's not any > harder - it'll just behave as a version control system that can buffer > commits offline with two "levels" of commit - local and remote.

That's hg. With git, you got the index / staging area, which is unique to git (no idea if bitkeeper has it). In other tools such as svn or hg, there is no need for flags such as "commit -a", "diff --cached", and "add -N".

> If you want to use the more complicated stuff, then there is no way to avoid > learning the more complicated ideas.

And this is what we hate about git. Version control shouldn't be complicated for 99.9% of projects. I have used svn for 3 years and hg for 2, they get the job done just fine without cryptic commands and flags.

</comment></comment></comment></comment></comment><comment><USER64> [http://stackoverflow.com/questions/115983/how-do-i-add-an- em...](http://stackoverflow.com/questions/115983/how-do-i-add-an-empty- directory-to-a-git-repository)

Git questions on SO with more than 300 upvotes should be considered bugs.

</comment><comment><USER65> There are plenty of abstractions on top of git - most UI implementations abstract away the hard details, at the cost of not being able to understand what happens when something bad occurs because you never had to learn its intricacies prior. Seeing the consequences of such things it makes me appreciate git is left as raw interactions. Git is not for people that do not want to understand it. To me, it's similar to vim - its basic implementation is bare essentials and complicated concepts, but once mastered, far outweigh competitors who roll those concepts up into simpler ones and leave you with workflows on their terms.

<comment><USER66> I completely agree with you here. Having used Visual Studio as my primary editor for a long time, I finally decided to give vim a try last year given how all my hacker friends raved about it. It definitely took a few days of understanding the basic concepts and going over the steep learning curve, but now I'm way more efficient with my coding than before.

It's been the same experience with git. It definitely has a steeper learning curve, especially coming from a centralized source control system like TFS and Perforce (for me at least), but having worked through that curve, I feel git has been much more useful to my workflows than what TFS or Perforce (or insert any central source control system) has ever been.

</comment></comment><comment><USER67> > Power for the maintainer, at the expense of the contributor

Interestingly, SVN and Perforce are about power for the maintainer, _with no benefit at all_ for the contributor. You can't even version control your own work with those tools.

</comment><comment><USER68> Issue #10.

        alias commit='git add && git commit && git push'

<comment><USER28> I know what you're going for, but for anyone following along at home: "To avoid confusion and troubles with script usage, aliases that hide existing git commands are ignored." (from git help config)

<comment><USER69> This is true, namely that _git aliases_ in ~/.gitconfig cannot override git built-ins.

That said, the parent post showed what looked like a bash alias, not a git alias.

<comment><USER68> The bash alias is correct. The issue was "too many commands", which is a non- issue. You type in the commands _once_ , make it an alias, and be done with it. When switching to another repository system, change the "commit" alias, not what your fingers have to remember.

</comment></comment></comment></comment><comment><USER70> git::mercurial vhs::betamax

I'll also say that tech folks don't like not being able to understand something, and enjoy understanding arcane things others don't (and once understood, no matter how hard it was to learn, it is suddenly "trivial"), further strengthening git's hold. I'm happy to see the author seems to understand git well enough to say, yes, I get it, and I still don't like it. I just wish he had talked about mercurial as the plausible user friendly alternative instead of svn, since svn is not distributed and therefor unsuitable for the use cases where git thrives.

</comment><comment><USER71> Whoever designed Git was both a skilled programmer and a crappy designer.

</comment><comment><USER72> I started dvcs with Darcs but it was too slow despite having a really really good CLI. Then I switched to Git because it was fast and within a week ran into so many sharp corners I had metaphorical blood all over my codebase. After a while I learned the useful subset of Git commands and life got easier with only an occasional sharp corner intruding every few months or so.

Then I discovered Mercurial. The speed was acceptable. The UI was intelligible. And I didn't hit any sharp corners. Life has been way way better ever since.

</comment><comment><USER73> i had to work on a big corp job once they were using VSS5 in 2007. made me appreciate even CVS.

if you want to have a really simple way of working with git get the github for mac client. at the same time insanely inflexible.

but hey you know what in theory vss5 is quite "simple" as well. i mean how complex can a program be where distributed work is essentially happening by locking files.

I had hoped op would've said something interesting that might've led into 3rd generation DVCS, but this is definitely far from.

</comment><comment><USER74> This sort of article sounds like s/unix/git/g of rants against UNIX/Linux command line & filesystem concepts that were common in the late 90's, as it was becoming clear that UNIX wasn't actually going to be killed by Windows NT, but rather was resurgent. Examples included:

\- "Yuck, why such different terminology from DOS?" \- "Commands are inconsistent and there are too many, where's my One Command or (better yet) One GUI that does everything they way I think about it?" \- "Yuck, scripts that make things easier for my particular workflow, why didn't they just build it right the first time?"

Fundamentally it comes down to people who believe version control is a simple problem, and git confuses that for no good reason, or those who believe version control is an inherently complicated problem, and tends to require some study to understand the concepts. Git doesn't hand-hold, it exposes the core concepts at the _data level_ , thus supporting any workflow for any size of team or work style. If you prefer a dictated workflow and task structure, there are plenty of wrappers that will help you - just don't be surprised if not every team agrees with your preferred workflow.

<comment><USER75> > it exposes the core concepts at the data level

But it exposes them _poorly_ , from a user interface standpoint. The beauty of UNIX, actually, is that it provided a few simplifying abstractions (block files, character devices, pipes), and everything used that. Imagine if catting the contents of something from /dev was different than piping the contents of a tarball. That's the sort of UI/UX frustrations that TFA (and others) rant about.

This is not a "DVCS vs. SVN/CVS" issue. This is about git's usability.

</comment></comment><comment><USER76> OP might have just professed "I am not technically advanced, Git has powerful features I'd never use, it should cater to me."

In general, there are too many of these articles on HN about "I don't know how to use it, so it's terrible."

What OP fails to grasp is the purposeful difference between Git and other revision/version control systems. Git attempts to cover anything you would ever want to do. Git is the Photoshop to SVN's Instagram.

You can use Git as if it were SVN, no problem. You can do Git commit-push-pull all day long as if you were SVN commit-update, and be none the wiser.

The one thing Photoshop has (as a similarly complex piece of software) that Git doesn't have is a single user interface. I don't see this as a problem. There are a bagillion Git GUI clients if you don't like the command line. Some are good, some aren't.

As far as having a good strategy for using Git on a real project. I think OP needs to spend some more time on Google. Here's a good article describing the most common workflow:

<http://nvie.com/posts/a-successful-git-branching-model/>

</comment><comment><USER77> As a new DVCS user, I today just started playing with both using tutorials and books freely available on the web. I am using Mint 13 and the CLI. Of the two, the feel I get is that Mercurial is easier (more straightforward) of the two to use and Git is the more micromanage-able of the two. JMHO, but as a newcomer, it's my impression.

</comment><comment><USER78> I especially liked the first comment about Subversion "anybody can write a simple VCS if they don't have to make it distributed." It reminds me of my days working on a parallel compiler team. We always used to say, "we can get you answers very, very quickly if you don't mind whether they're correct or not."

Just as a parallel compiler developer must worry about recurrences and data dependencies breaking parallel programs, distributed version control adds a huge level of complexity which you cannot safely hide. However, I agree with the poster that the next major version of Git should clear up several inconsistencies.

(As a side note, some binaries labeled as ASCII in our Subversion repository back then caused massive corruption and shut down all development for days. Having too many assumptions made by your VCS and too few options specified by developers is bad simplicity!)

</comment><comment><USER79> Subgit and Subhg are interesting.

[http://rustyklophaus.com/articles/20100124-SubmodulesAndSubr...](http://rustyklophaus.com/articles/20100124-SubmodulesAndSubreposDoneRight.html)

Just use Mercurial for random private commits, send the Git people your changesets every so often:

        $ git init && git add . && git commit -m "Initial commit" && git remote add origin firstname.lastname@example.com:acct/repo.git && git push -u origin master
        $ subgit setup
        $ hg init

hginit.com <\-- great resource

<http://code.google.com/p/support/wiki/DVCSAnalysis>

In Google's own words: "In terms of implementation effort, Mercurial has a clear advantage due to its efficient HTTP transport protocol.

In terms of features, Git is more powerful, but this tends to be offset by it being more complicated to use."

</comment><comment><USER80> I really can't agree with point #1. Most of the things he lists as being part of the complex information model are _equivalent_ and make perfect sense once you take a couple hours to understand how git works internally.

And no, that's not too much to ask for a tool that you will be using nearly every day. Once you understand git's data model and "patch-oriented" behaviour, you won't have to wonder about namespaces, the index, rebasing, cherry picking or fast-forward merges.

Point 5, or the fact that Git doesn't even try to hide its internal workings is actually why I prefer it over everything else. The UI can be weird at times since it evolved from just a collection of tools to operate on an on-disk, persistent and immutable data structure, but as far as being good at what it does, it's hard to beat Git.

</comment><comment><USER81> _Translation: "It's easy, Granny. Just rev to 6000, dump the clutch, and use wheel spin to get round the first corner. Up to third, then trail brake onto the freeway, late apexing but watch the marbles on the inside. Hard up to fifth, then handbrake turn to make the exit."_

Haha!

</comment><comment><USER82> I felt the article had some fair complaints. The problem is that the author felt that going back SVN was the resolution to those complaints which I found ridiculous.

My question is how does mercurial compare to git on all of the author's points?

<comment><USER27> As someone who jumped from svn to hg a long time ago, I can answer simply: the transition was smooth like butter, <http://hginit.com/> explains everything on the concept, while hg's ui provides abstraction and is very svnuser-friendly, so - everything just works. <http://hgtip.com/> is also very useful.

IMO it's easier to embrace git after mercurial, because the part where you understand how a DVCS works is already behind you, and you jump into the syntax and specific differences.

</comment></comment><comment><USER83> The issue with git is that's got all this cruft built around it, but for the most part it's very rare you need to jump into it in that level. I've been using git for about 2 years and only needed to rebase for the first time very recently.

There are issues, and flaming the author saying he needs to read more is disrespectful (and ignorant of the issues), but git is a community, open source project. Not happy with the existing docs? Rewrite them, call it git for humans and off you go. I've seen projects doing work to 'nice' the command structure, so there's other people attempting it.

But we can all agree git reset is _weird_.

</comment><comment><USER84> I have used subversion heavily. So many things are not at possible with SVN. But, it can be done in Git easily. Of-course, it requires learning and a bit of change in the mind-set. But, it is worth it.

</comment><comment><USER85> I hate blogs that put pop-ups over part of the content with no way to close them (I'm not subscribing to your mail list or following you).

I don't hate Git but I do agree with many of your points. There's ccomplexity that should be hidden (or more hidden) and there's inconsistencies that still catch me occasionally. I've never actually lost code on Git though it's taken me a while to find my code.

It's also not fair to confuse Github's "Pull request", "Fork" and "Merge" with Git. These are still just branches and merges.

</comment><comment><USER38> 1\. Not sure his issue here - I count 9 things you need to know for Github (one of which I have _never_ needed to know - treeishes), and 7 things for SVN. It's really not that complex.

2\. The command line syntax:

 _But the shortcut for "git branch" combined with "git checkout"? "git checkout -b"_

Indeed. You can branch your code, but not check out the files from the index into the working tree.

Perhaps the confusion here is because the author is coming from an SVN background, where checkout means something different.

As for git am being obscure - sure, seems a little, but then there are two things: 1. don't use it if you don't need it, and 2. for kernel development, this is remarkably useful!

3\. Documentation: completely invalid. The man pages might seem a little terse, but then if you are looking up a command and you don't understand the terminology, then you should probably consider typing in

      man gittutorial

Which, incidentally, can be found here: [http://www.kernel.org/pub/software/scm/git/docs/gittutorial....](http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html)

Alternatively, if you are trying to understand how to use git (and it might be worthwhile for the author to follow this advise) then try reading the git user's manual, which can be found here:

[http://www.kernel.org/pub/software/scm/git/docs/user- manual....](http://www.kernel.org/pub/software/scm/git/docs/user-manual.html)

Hint:

git rebase is explained here: [http://www.kernel.org/pub/software/scm/git/docs/user- manual....](http://www.kernel.org/pub/software/scm/git/docs/user- manual.html#using-git-rebase)

To understand how git checkout works, read here: [http://www.kernel.org/pub/software/scm/git/docs/user- manual....](http://www.kernel.org/pub/software/scm/git/docs/user- manual.html#how-to-check-out)

4\. Information sprawl: actually, I consider myself to be a git newbie (mainly use github!) and frankly I've not needed to learn that much about git so far. However, whenever I've come up against something new, I've checked the documentation and after about 5-10 minutes I've understood the concept needed to get me going. I don't consider myself to be an expert in git in any way. However, as someone who has to program, I tend to find that for any system with enough power, I have to learn new things regularly. git is one of those things. Learn to love it :-)

5\. Leaky abstraction: first, don't make the title "leaky abstraction" if you don't believe that there is any abstraction in the first place.

Secondly, it looks to me like they are trying to take your branch and insert it into another repository? Can't quite tell what is required here... certainly I'd love to see the way that this would be done in SVN!

6\. Power for the maintainer, not the user...

??? I'm sorry, but the author is complaining that git is powerful, and works really well in highly distributed systems where you have a lot of parallel commits? Well, uh... duh?

The complaint here is that it's not usable for "ordinary" repository users. I would consider myself a fairly ordinary user, and I can honestly say that I don't consider that git is that hard to use.

7\. Unsafe version control

DON'T DO THOSE THINGS!

8\. _In the traditional open source project, only one person had to deal with the complexities of branches and merges: the maintainer. Everyone else only had to update, commit, update, commit, update, commit…_

Which meant a massive bottleneck when doing branching and merging. That's the whole point of git - it's version control done large. Or otherwise known as "distributed version control". I'd recommend the author read up on some of the advantages here: <http://git-scm.com/about>

9\. I don't really have much of an opinion on this.

10\. Github != git. For the record, I love github and I really don't find it that hard to use, or anything so complex that I can't do it fairly quickly.

<comment><USER86> _Documentation: completely invalid. The man pages might seem a little terse, but then if you are looking up a command and you don't understand the terminology, then you should probably consider typing in..._

I think a cardinal virtue of documentation is to but info where people expect to find it. Saying "Oh, you read the MANUAL. When I said RTFM, I mean the MANUAL for the TUTORIAL" isn't much of a help. If the documentation isn't where novices expect to find it, it doesn't exist.

 _Unsafe version control

DON'T DO THOSE THINGS!_

How many can be done by accident? Are you using revision control at least in part for the ability to recover from a stupid accident? The fact that it isn't safe means you can't count on it being safe. You can't use it as essentially a way to have real point in time recovery for your repo, and it also means you can't count on it being an audit trail because at a minimum it could bet wiped out. That's fine, but it's worth stating up front that this is something Git doesn't do very well. Fine. Understand it is a tradeoff.

<comment><USER80> Doing those "unsafe" things in git by accident in a way that is unrecoverable pretty much requires you to be so drunk that you wake up the next day not remembering what you have done.

forcefully pushing things to remote repositories can be denied with hooks, so if you really do not trust the people with push access you can use that. For anything else, it's pretty much always possible to undo any damage by using the reflog.

In my experience, git is the least unsafe VCS I've used. if I commit a file, I know it's safe from accidental removals (as long as I don't touch .git). If I push the commit to a remote (private or public. Could even be on the same machine), it's safe from _anything_ I do locally. So if I am going to do a complicated merge or a rebase, I first make a temporary commit to save the state of the repository and ensure that I can always undo any mistakes. You can't always do that in svn, since commits are immediately public.

<comment><USER86> _Doing those "unsafe" things in git by accident in a way that is unrecoverable pretty much requires you to be so drunk that you wake up the next day not remembering what you have done._

Or more likely not knowing what you are doing, getting disoriented and combining the wrong options.

I haven't been using git for that long but I could totally see myself getting confused and typing something like that in by accident.

<comment><USER87> Even then, you can get back to something sane by using the reflog: master@{yesterday} refers to the master branch as it was 24 hours ago, and you can view the different things you've done to HEAD by just running `git reflog`. It's really _really_ hard to blow away the reflog without meaning to -- you're much more likely to just `rm -r` the whole repository by mistake.

</comment></comment></comment></comment></comment><comment><USER88> This is a pretty decent criticism of git's _current UI_. The good news is that the core primitive operations underlying git are fine, and all that needs to be done is to create a better UI out of them. There's definitely room to build a great, user-friendly (commandline) user interface for git. I'd bet that the existing high-level operations like "push" and "pop" were relatively late additions.

</comment><comment><USER89> Yet another "i hate <this>" article :-)

<comment><USER38> Indeed. It seems to be a "I hate git, because I don't understand what it is trying to achieve, and I haven't bothered to learn the concepts".

Unfortunately, this tends to invalidate many of the points he is making. The author is assuming that git should work exactly the same way as subversion, except that it has a fundamentally different way of viewing version control and uses it's own terminology which can sometimes get in the way of those who know subversion.

<comment><USER30> I think you are missing the point. The author is talking about unnecessary complications. Git is unnecessarily difficult to work with and understand. He is debating whether and how much of any of these is necessary. Sure we can spend time and learn it, but why should it require this much learning in the first place?

<comment><USER38> What part, exactly, is so hard to understand? All the examples he gives aren't particularly hard to understand.

For example, he complains that git pull is actually git fetch and git merge... well, that's pretty obvious. First you have to fetch the changes, then you have to merge in those changes. What is particularly illogical about that?

Another example: he complains that _git branch_ combined with _git checkout_ is _git checkout -b_ (he forgets to note that you specify a branch name...). What's so non-obvious or "insane" about that? First you create a branch with _git branch newbranch_ , then you checkout files from a branch with _git checkout <branch>_. The obvious shortcut is _git checkout -b newbranch <branch>_: when you want to create a new branch, then you have to checkout the files from a branch, and the -b creates a new branch for you before you do that.

The only real thing that is a little tricky to understand is the concept of refs, but even that's not really that hard to understand. Every commit has a SHA-1 reference to it, and a branch is merely a reference to a particular commit that is the head of a line of work.

Remote refs are about the only other type of ref that you need to know about - all they are is a reference that points to a remote repository that you can push to or fetch from.

Once you know what a ref is, most of the man pages make sense. Thus when the man page for git-push says:

      git-push – Update remote refs along with associated objects

... you can see that it means that it will update the remote refs (remote repositories you are pointing to). Which is what he says in his article, but all he has to really do is understand what a ref is and he wouldn't be so confused.

When you think about refs, they make logical sense - all they are is like a "remote branch" of your repository.

As for complexity in the concepts, let's look at what he's complaining about:

 _...you have files, a working tree, an index, a local repository, a remote repository, remotes (pointers to remote repositories), commits, treeishes (pointers to commits), branches, a stash_

1\. Files - <USER3>

2\. A working tree - you do your work in the working tree

3\. An index - once you have made your changes in the working tree, you commit your changes to the index

4\. A local repository/a remote repository - this isn't a particularly hard concept to understand. You do you work in your own local repository. You might get that repository from someone else. You make your changes in your own repository, then you push those changes to a remote repository.

Not entirely sure what is so difficult about that concept...

5\. Remotes - again, not a particularly hard concept really, as he says these are just references to remote repositories

6\. Commits - You work away on your code in the working repository (whatever directory structure you so desire). Then you commit it to the index. Which is not really any different to SVN, where you checkout a file from the SVN repository, then you make your changes, then you _commit_ your change back to the repository.

Explain to me again what is so hard about this concept?

7\. Tree-ish - This is an extremely advanced part of git that most users may never encounter. You most certainly don't _need_ do know about this, though of course it is always good to do so.

8\. Branches - we _are_ talking about source control? If so, what is the issue here? Branches are not really any different in git than any other source control system.

9\. Stashes - an extremely useful feature. If you are in the middle of working on something and you want to switch branches, you normally don't want to commit those changes. So what you do is "stash" the changes onto a stack. You can reapply them later. Some excellent info can be found here: <http://git- scm.com/book/en/Git-Tools-Stashing>

There... none of that was so hard, was it?

<comment><USER90> >> All the examples he gives aren't particularly hard to understand. For example, he complains that git pull is actually git fetch and git merge... well, that's pretty obvious.

No, it isn't since the words fetch and pull mean pretty much the same thing to most people.

>> What part, exactly, is so hard to understand?

Looking at the length of your comment...apparently a lot, for most people.

I've tried to like git, I want to like git, I don't get git. So ... in Eclipse at least I use EGit to help me make git usable. Even with that tool to make git easier to understand I still find it confusing (or confounding).

<comment><USER38> _No, it isn't since the words fetch and pull mean pretty much the same thing to most people._

All I can say is that there are valid design decisions for seperating the two. That's why they created the shortcut - to make it easier to do what folks intend to do. When people do a pull, then they get what they want. That is the common nomenclature of git, pretty much everywhere.

And to be clear, the man page for git-merge can't be any clearer:

      git-pull - Fetch from and merge with another repository or a local branch

_Looking at the length of your comment...apparently a lot, for most people._

Which I would argue is because they are coming from SVN, and apply their experience with SVN to git. That's not really a problem for git, IMO, but more an issue for those who believe that SVN is the only way to go about doing source control.

</comment></comment></comment></comment></comment></comment><comment><USER91> While I agree with the article in many of its finer points, the hyperbole ruins its effectiveness. For example, I don't find it frequently necessary to "log on to github and issue a pull request" to commit changes. Additionally, github != git, blaming one for the sins of the other just muddles things further.

</comment><comment><USER92> Point 10 is not a fair comparison, since the svn example does not cover passing around patch files and trying to keep multiple svn repos in sync.

How can this article complain about syntax and documentation, but leave out a discussion of submodules. As much as I like git, that's really the worst part.

</comment><comment><USER93> What I hate about git is the religious fervor surrounding it. It's a tool. And energy spent debating the good or bad of any tool could be better spent building something amazing.

</comment><comment><USER94> There's a lot of unfair or simply untrue comparisons in that post.

</comment><comment><USER95> Interesting point of view but it please try to learn your tools better next time you write an article :) And try not be a hater, it only harms you and not doing any good.

</comment><comment><USER96> thanks for a nice list. i also dislike git for many of the same reasons. i think it's crap based on those reasons, and i'm saddened it's taken off.

</comment><comment><USER97> I like GIT. If the man pages were improved to be more human readable then I think a majority of all these "i hate git" articles will go away.

</comment><comment><USER98> This is why the big boys still use Perforce.

</comment><comment><USER99> Another crybaby blog post by someone that wishes it were still 1997.

If git syntax is that hard, then programming might not be the correct vocation.

</comment><comment><USER100> Back to SVN via email, and flash drives! I'm so glad my last day is Monday.

</comment><comment><USER101> It would only take a week to properly learn git. Most people spend a lot more time to learn a programming language or an operating system.

I consider git to be almost like a programming language.

The information model is not complex, it's actually quite simple if you really understand it.

* blob: roughly a file (without a name)

* tree: roughly a dir (maps names to blobs and trees)

* commit: tree + parent commit(s) + meta data (author, commit msg, etc).

If you grok this core data model, a lot of things will make much more sense.

<http://git-scm.com/book/en/Git-Internals-Git-Objects>

I don't know if anyone shares my experience, but I actually found svn rather mysterious and difficult to understand. I never actually saw the point to it at all, so I never bothered using it (unless it was mandated by some authority).

It's only when I understood git that I really understood what version control is supposed to be about.

So, I think people who try to "dumb it down" by giving tutorials that ignore the data model and focus only on the usage are not doing anyone a favor.

Git should be treated like a new programming language or a new operating system. Spend a few days reading (or watching youtube videos) about how it works and why it was designed this way.

Yes, you really have to understand how it works. But it's precisely the fact that you _can_ do so, that make git the best version control system out there in my opinion.

<comment><USER14> Taking a week to learn a computer utility seems insane to me, I think that's one of the problems.

People just want some version control, they don't _want_ to learn a whole programming language to have to do it.

Imagine if I had to spend a week learning how to configure my screensaver, set up hard drive backups, or install Dropbox? Forget about it.

Now if git were only popular among super-power-hard-core programmers, then I don't think there would be any criticism. But it's the fact that it seems like pretty much everyone has switched to git now, because its advantages are fantastic, but it takes 100x longer to learn than any other tool I've ever used.

<comment><USER31> Oh come on.

Your language, your editor, and your source control. Three things worth knowing backwards and forwards if you're going to call yourself a developer. Three things _easily_ worth spending a week grokking, if necessary.

<comment><USER29> And then there's the thousands of libraries, debuggers, versions, deployment choices, design strategies, etc etc. Development is an endless path of learning, and git is barely learnable.

And editors don't take a week to learn because you don't have to learn everything to use them. Even vi works quite well with just a few commands, and you will never NEED anything other than those, only optimize your usage.

<comment><USER38> "git is barely learnable" - hardly!

<comment><USER29> The fact that even experts admit they don't understand the array of options and implications for commands like reset and rebase would tend to support me here.

And there is always dispute about the best way to do something as simple as back out a commit or clean large old files from a repository (very difficult with a large team). The series of incantations to do such things is always ridiculously obtuse, with non-intuitive flags and symbols.

Sure the basics are learnable, and google can often reveal solutions (though rarely definitively), but I know no one with a comprehensive understanding of the majority of git fundamentals.

<comment><USER38> I wouldn't be calling someone an expert if they don't understand what a rebase is.

<comment><USER25> "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." -- <http://gitref.org/basic/#reset></comment></comment></comment></comment></comment></comment></comment></comment>


How to use Google's large-scale graph processing architecture Pregel in ArangoDB - <AUTHOR> https://www.arangodb.com/2014/11/18/intro-pregel-module

<comment><USER2> Interesting article. What kind of graph algorithms can be implemented in this Pregel framework and how compares the complexity of this approach to specialised algorithms not using the framework? Nay hints or references would be appreciated.</comment>


While iPhone sales remain stagnant, Apple services hit $10B in revenue - <AUTHOR> https://arstechnica.com/gadgets/2018/11/apple-services-reach-a-whopping-10-billion-in-revenue-in-q4-2018/ <comment><USER2> Given that Samsung just reported a 33% drop in smartphone sales from the same quarter last year, Apple reporting a .4% increase in their smartphone sales vs the same quarter last year sounds pretty good.

[https://www.telegraph.co.uk/technology/2018/10/31/samsung- re...](https://www.telegraph.co.uk/technology/2018/10/31/samsung-reports- record-profit-despite-smartphone-sales-slump/)

[https://www.anandtech.com/show/13540/apple- announces-q4-fy-2...](https://www.anandtech.com/show/13540/apple- announces-q4-fy-2018-earnings-revenue-up-sales-not)

<comment><USER3> I think we should attach an important health warning. Samsung release their S9 in March 2018, whereas Apple released the iPhone X in November. So this quarter is the drop from Samsung's first full quarter of their new flagship sales to one year later. Apple's quarter is the drop from the last full quarter before their new flagship to a quarter where they released a new flagship.

<comment><USER2> Both companies have a similar release schedule every year, which is why we compare to the same quarter a year ago.

Unfortunately for Samsung, falling smartphone sales figures have been an ongoing problem.

>Samsung's mobile phone sales have been taking a hit this year. It's a downward trend that started during last year's holiday quarter and has persisted throughout 2018. Both IDC and Strategy Analytics report that Samsung's smartphone sales have dipped around 13 percent in the recent quarter. That follows a 10 percent decline in Q2, a 2 percent drop in Q1, and a 4 percent dip in Q4 2017. It's a clear sign that Samsung's Galaxy Note 9 and Galaxy S9 devices haven't been competitive at the high-end

[https://www.theverge.com/2018/11/2/18055094/samsung- smartpho...](https://www.theverge.com/2018/11/2/18055094/samsung-smartphone- sales-decline-2018-report)

<comment><USER3> I don't think that it's fair to say that Apple's release schedule has been similar between now and the previous year. Last year the iPhone X was announced in September and released in November/December (by region) and it was arguably the biggest upgrade Apple made since the iPhone 4. So it's fairly obvious that Q3 2017 was an almost uniquely low year. Compare that to Q3 2018 where Apple announced AND shipped the iPhone Xs in September.

I don't disagree that there's a larger trend going on, I'm just saying that this isn't a particularly good data point because there are other underlying factors.

<comment><USER2> Apple is one of those companies whose fiscal year doesn't match the calendar year.

The numbers that were just released are for their fiscal fourth quarter which covers sales through the end of September, so we are talking about a couple of days worth of sales in 2017 with only the (then) new iPhone 8 variants for sale but not the iPhone X and a couple of days worth of sales in 2018 with only the iPhone XS variants for sale but not the iPhone XR.

I don't really see any calendar related difference for Samsung's flagships between 2017 and 2018.

I don't see any of that being greatly material when you look to explain the difference between a tiny year on year smartphone sales increase for Apple and a massive year on year smartphone sales drop for Samsung.

</comment></comment></comment></comment></comment><comment><USER4> The average sales priced for an iPhone increased nearly 30% from $618 to $793. Services now account for 16% of revenue. Apple is gradually shifting from a device maker to an ecosystem company that consumers pay a premium initial fee to enter and pay an additional recurring free to use.

<comment><USER5> Yet services would be better if units sold gets increased. So cheaper models are a must. So it's so far an excellent strategy milking the high end keeping the units sold not fall.

<comment><USER4> Services might be better, but I suspect that budget conscious consumers would also spend less on services, compared to customers willing to spend $1200 on an iPhone XS. I imagine their FP&A team has done pretty thorough analysis that the extra sales from fewer products at higher margins will offset the incremental increase in revenue from more (potentially lower value) services subscribers.

</comment></comment></comment><comment><USER6> I mean sure 'Stagnant' means that there was no growth, _but it also implies_ that this is a bad thing, which in this case it obviously isn't. Clickbait title.

<comment><USER7> How high do you think they can go in term of prices? And do you think they will sell many £1000 smartphones in a recession? Stagnant volumes is not an imminent problem but the share price is a forward looking metric.

<comment><USER8> iPhones might be a Veblen good. They could probably release a $5000 or $10,000 model and there would be a market for it. Plenty of people buy $50,000 watches.

<comment><USER9> Didn't Apple stop making the super expensive Apple watch, though?

<comment><USER8> The Apple watch is a low-status dorky, uncool watch. The iPhone is a cool, high-status phone.

<comment><USER10> Patek Philippe or nothing!

</comment></comment></comment></comment></comment></comment><comment><USER11> Stagnant sales with a much more expensive smartphone, i don't think anybody wouldn't live to have the same "problem".

<comment><USER5> Many analysts thought higher average selling prices were possible because of demand inelasticity at the forerunner iPhone.

Service revenues would get boosted by lower prices if units sold increase.

Cook is doing a fine balance of prices, sales, services. Very successful so far. Yet I'm afraid the only way is down from here.

<comment><USER12> Why down? If iPhone sales remain stable, which they should, iPhone customers are extremely loyal; as long as they continue to grow in their Other and Services category, there will be a lot of growth for the company.

Plus whatever device that comes out for AR will be interesting. Apple still continues to understand strategy and the technology landscape better than any other company.

<comment><USER7> You think customers are going to spend more than their rent into their smartphone?

<comment><USER13> We're a very long way from that. Do I think customers will continue to buy a smartphone every couple years AND also pay $20-30 per month for various services like music, tv shows, software, etc? Yep.

</comment></comment></comment></comment></comment><comment><USER14> Apple services definitely are on an upward trajectory for quality and breadth. Two years ago I thought Siri was a bit of a joke because the voice recognition and accuracy/usefulness of results was not there for me. Different now: about 4 months ago I deinstalled the Google Assistant from my iPhone and now just use Siri. Siri is still not as good but there is the privacy issue. Siri is good enough for me.

I still prefer Google for the Play Music + commercial free YouTube bundled service, and also GCP is my favorite cloud service.

<comment><USER15> Out of curiosity, what do you use Siri for that it can be good enough?

I use Siri almost exclusively for reminders (e.g., "remind me at x PM to do y" or "remind me when I get home to do z"), and even with this limited use case I often end up with baffling reminders in the future (my favorite reminder is to "make farts"\--I never did remember what it was supposed to be.) Beyond reminders I've yet to find a compelling, reliable use case.

<comment><USER16> It's amazing that I would be having a random discussion and to check a fact, I would ask Google because Google Search Engine.

Google reads the answer in a natural human like way. It works well.

Countless dinner arguments arbitrated by Google via Google Voice by a simple ask. Shit saves marriages I bet.

"wtf you mean the Mongol Empire didn't last long? hold up, lets ask Google about the Crimean Khnate that still kicked ass up till the 17th century"

"i dont fucking believe you, i want a divorce"

"...ey google what year did Crimean Khanate close"

 _During the 16th and 17th centuries, the Crimean Khanate was an important center of the slave trade. In 1774, it was released as a nationally independent state, following the Russo-Turkish Treaty of Küçük Kaynarca, and formally annexed by the Russian Empire in 1783, becoming the Taurida Governorate_

"thank you Google for saving our marriage"

 _Your welcome._

\--goes to work the next morning, sees divorce lawyer ads--

<comment><USER13> Your marriage is very different than mine. Not just because of what you argue about, but because you think the injection of a fact provided by a robot in the cloud is what's missing from the path to de-escalation.

<comment><USER16> wow, that is some seriously good insight.

next time I will marry Google Home

</comment></comment></comment></comment></comment><comment><USER17> Maybe if the price of an iPhone wasn't MORE than buying a decent a laptop then their sales wouldn't be stagnant.

</comment><comment><USER18> stagnant /ˈstaɡnənt/ – showing no activity.

so they're selling 0 iphones? really?

<comment><USER19> Wiktionary says

> 1\. Lacking freshness, motion, or flow; decaying through stillness.

> 2\. (figuratively) Without progress or change; stale; inactive.

A stagnant pond isn't empty, the water just isn't moving or changing. Same with sales numbers here.

</comment></comment><comment><USER20> Stagnant is not a fair way to describe selling 46.8 million iPhones.

<comment><USER21> Stagnant implies it's not growing, not that it's not selling.

<comment><USER22> Stagnant carries a connotation of some dark, oxygen-deprived mire that suffocates fish and smells horrible. It invokes images of death and decay. Not exactly the idea I had in mind when I hear of the sales numbers.

<comment><USER23> _Not exactly the idea I had in mind when I hear of the sales numbers._

The global market size for mobile phones is still growing. If Apple's sales aren't growing at least in line with the size of the market then their market share is shrinking. Selling a lot in a stable market is great. Selling a lot in a growing market is ... less great.

<comment><USER24> What market are you talking about? Apple is only in the premium phone market.

<comment><USER23> _Apple is only in the premium phone market._

I must have been talking about the premium phone market then, obviously.

<comment><USER25> Which premium mobiles are getting growing volume right now then?

</comment></comment></comment></comment></comment></comment></comment><comment><USER26> Apple takes a 30% commission on any revenue passing through the store, and 15% on subscriptions.

These fees are exorbitant - they are merely ringing a credit card, transmitting a few megabytes of data, and performing a basic examination of the app itself. The oligopolistic position that they hold is their main point of value.

<comment><USER20> Its also ironic apple are suing Qualcom regarding licensing fees which are paid as a percentage of the hardware cost, as they believe that this means Qualcom profit from apples innovation unfairly, you could argue that Apples policy is the same with the App Store - why do they get a percentage? They add no extra value for high value transactions, surely a low fixed fee would be more aligned with apples values :)

<comment><USER27> Because most of the R&D that Qualcomm does (and as a fabless, IP is their real business) ends up on Android phones, while Apple pays the biggest slice.

Therefore, they are getting their chips from Intel.

Apple doesn't have anything to do with Qualcomm anymore, they get the package from Intel.

Qualcomm can battle Intel in court if they want. Good luck for them...

<comment><USER20> I guess I mean the principle that a percentage is taken - why should apple take more of a higher price transaction when there are no material differences in cost to them?

</comment></comment></comment></comment><comment><USER28> It's all about the #donglelife and getting everyone to pay for having an ios app.</comment>


Razer Acquires Ouya's Software, Tech and Dev Teams in All-Cash Deal  - <AUTHOR> http://techcrunch.com/2015/07/27/razer-confirms-ouya-acquisition/

<comment><USER3> More info is available at Polygon:

[http://www.polygon.com/features/2015/7/27/9046895/razer- ouya...](http://www.polygon.com/features/2015/7/27/9046895/razer-ouya-android- why)

</comment><comment><USER4> The Techcrunch article linked in this article has a lot more details, including statements that sound a lot like "your Ouya console will be useless in 12 months - go get a Razer Forge box after that."

<comment><USER5> Why would one expect the usefulness of their Ouya console to change and be anything other than useless? (this is a joke at Ouya's expense, I am pointing it out because based on my past experience making jokes here someone will take this seriously and get all defensive about how great Ouya is)

Seriously though in 12 months Ouya will be 3 years old, I don't think expecting a company to actively support a piece of cheap (affordable for those that find the word cheap insulting) hardware for more than 3 years is a reasonable expectation. Ouya had already added the play store I thought (as pointed out below, I thought wrong), and so discontinuing support will probably amount to the Ouya store ceasing to exist and a lack of future patches. I mean its a device to play games mainly in a local manner, it will continue to be able to do that as well as it can now.

<comment><USER4> Isn't it interesting how 3 years is such a long time to support things now?

<comment><USER6> I just bought a washing machine with a ten year warranty, to replace one made in the 80's for which there are still official spare parts (but that I felt was better off being replaced than repaired). You can find companies who are in it for the long haul, but it is true that most aren't.

<comment><USER7> Washing machines don't have twice as much wash performance after five years, though. Apples and soup cans.

<comment><USER8> With all the indie & low tech games around, I suspect console power doesn't double the enjoyment/thrill factor every 3-5 years either.

</comment></comment></comment></comment></comment></comment><comment><USER9> I actually think the Ouya was a very nice idea, and clearly so did a lot of people who backed it. The execution was awful on so many levels, but there will probably be room in the market for something like this once the console market is done shifting => non-existent. I would guess it will be part of something like the Apple TV box though.

<comment><USER10> What could have been done besides throwing more money at it?

How did Microsoft get the original xbox into a state of relevance?

<comment><USER11> "How did Microsoft get the original xbox into a state of relevance?"

By dumping an insane amount of money into it, and waiting until the 360 to actually make any profit whatsoever. Not easy to replicate.

<comment><USER3> I have no idea why people are downvoting this, as it's pretty accurate. If anything it understates the difficulty. The original Xbox cost tons to develop, and Microsoft spent a lot more money getting games for the thing. In the process they created the canonical example of a console first-person shooter, the genre that now dominates game sales. (You could argue that Goldeneye and Perfect Dark on the N64 got there first, but Halo is the one that really moved the market to where it is now.) Then on top of that, they created Xbox Live, which has had at least as much impact on how we play games as Halo did. And you're absolutely right that they lost money in the process. So yeah, dumping an insane amount of money into creating two products that revolutionized the game industry and not recouping that investment until the the second-generation product launched is how they did it.

<comment><USER12> "Created" is a strong word for Microsoft's contribution to Halo, given the original debut of the game at MacWorld: [https://www.youtube.com/watch?v=x2RMHeMGDDU](https://www.youtube.com/watch?v=x2RMHeMGDDU)

<comment><USER3> If we're playing the pedant game, what I said was:

> In the process they created the canonical example of a console first-person > shooter

Whatever one thinks about Microsoft's involvement in Halo, it wasn't going to be a console game at all without them. And I don't think it's the game that changes the whole industry if it's not the game that brought PC's biggest genre to consoles in a way that made them feel like they belonged there.

</comment></comment></comment></comment></comment></comment><comment><USER13> Damn, i did not know Ouya was still relevant. I had assumed that the idea had fallen down to obsolescence land. Jokes on me though, they just pulled in 10M.

<comment><USER14> After raising 33M from VCs, a 10M exit leaves everybody with nothing… Likely, the investors got some cash for the IP, and the rest went into retention bonuses.

<comment><USER15> Well, everyone gets nothing except the people with the retention bonuses - <USER2> employees.

So, money was funneled from rich VCs to workers? I'm... okay with this.

<comment><USER16> Article says VCs got their money back, which in all likelihood means employees got nothing.

<comment><USER15> In my experience with acquihires the employees usually end up with a pretty nice package of RSUs, while the VCs take a huge loss. They don't make money on the exit, but they do well.

</comment></comment></comment></comment></comment><comment><USER17> Ha! Why would anyone buy one, or a sequel to it, now that it is made by the company that required an internet connection to use their mouse?

</comment><comment><USER18> Url changed from [http://www.gamasutra.com/view/news/249573/Ouya_buyout_confir...](http://www.gamasutra.com/view/news/249573/Ouya_buyout_confirmed_as_CEO_leaves_company.php#.VbZLPu36O90.twitter), which points to this.</comment>


Site linking coders to non-coders - <AUTHOR>

Is there a site available that basically acts like a dating site for those that are technologically advanced and those that are not, specifically with regards to startups? I know the common answer is to learn how to code,but are there other alternatives? <comment><AUTHOR> Ha.Dating was just a description. Elance.com is nice, but it doesn't foster partnerships. It's more of a buyer-seller agreement. I am more interested in looking for partners in business.

BTW, I have no interest in creating the site. I'd just like to use one if it existed.

</comment><comment><USER2> elance.com (and similar sites for freelance projects) would be a starter for many, many business people looking for technical execution of their idea. You can also "Ask HN" for any interested developers, presenting first your idea roughly.

I don't think there is any need for special "dating" sites here - there is a business to be made, no chitchats with photo exchange are needed ;)

Good luck!

</comment><comment><USER3> <http://techcofounder.com></comment>