[xja]

Amusing and depressing, awesome stuff.

Git's rise to become the de facto standard revision control system has been fascinating to watch.

I think it does provided real benefit over Subversion, but there are also smaller projects where the gain is marginal.

The tooling around (in particular GitHub) and perception that git is the "right" way to do things probably helped it achieve prominence. As well as early adoption by a few high profile projects.

[SOLAR_FIELDS]

It's well designed in the open source philosophy. It's designed for people who are spread all over the world, working together but in seperate, isolated repositories. There probably well are quite a few use cases where Git is not the best suited tool for the task. I don't doubt there are several situations where a team's workflow can be improved and sped up by everyone using SVN, especially if everyone works together and in the same building for the most part.

That being said, most complaints about Git are of its difficulty for newcomers, non straightforward workflow, and lack of clear, concise documentation. Once the concept is reasonably grok'ed, one would likely be hard pressed to find a developer who prefers a centralized system such as SVN over Git.

[throwanem]

It's well designed in terms of the underlying concepts and functionality, which are (mostly) brilliant. Its user interface is a landfill fire.

[geezerjay]

> Its user interface is a landfill fire.

Are we talking about the same Git? Its command line interface is quite straight forward and very simple to use to perform the usual everyday tasks.

Can you actually point out a single example of what you perceive as a "landfill fire"?

[shaftway]

Can you give a succinct definition of what `git add` and `git checkout` do without relying on documentation?

[geezerjay]

Is it that hard to understand that `git add` adds files to the list of files tracked by the repository (which is updated when changes are committed to it) and `git checkout` checks out a version that has been previously committed?

I mean, that's pretty much how all version control systems operate. Is it that hard to wrap anyone's head around the basic functionality that is common to any version control system in use?

[throwanem]

No, it's not that hard to understand. It's also not how Git actually works. You're ignoring, or perhaps forgetting, the concepts of the index ("staging area"), and the many and various things which both these commands actually do, and the fashions in which these sorts of "oh, it's simple, really!" elisions betray those not yet experienced enough to recognize them for the overextended abstractions they are.

[throwanem]

I'm talking about the same Git as the article author is. If you have a different Git in mind, please point me to it! Perhaps I would prefer to use that one instead.

[geezerjay]

I see you failed yet again to provide any example to substantiate your baseless claims.

[throwanem]

The article's full of them! That wheel doesn't need reinventing.

I get that you like Git's UI, or at least don't mind it. That's fine. Others feel differently. That's fine too.

[cellularmitosis]

This is the most obscure command mentioned in the article:

    git rev-parse --abbrev-ref HEAD

[ozim]

He? Branching in GIT is natural thing to do where in SVN it is at least not user friendly.

"Subversion has no internal concept of a branch—it knows only how to make copies"

Now even if I do not need distributed features of git, I have VCS with local repo with git and I have easy branching. So even if I work on my side project I use branching a lot because I can do cheap experiment branches, go back to previous state or pick what I liked in my experiment. For me it is just totally different approach to development. When I stopped using Subversion and started using GIT my world changed for better, GIT gives me more control. I can pick parts of files to be staged or pick what I need to be commited. Where partial commits with subversion is at least black magic.

So even for smaller projects it is like a whole world of difference for using GIT.

[just2n]

I don't understand the hostility towards it. These types of complaints like "oh if you misuse this tool that you didn't bother learning about, it does things you probably didn't expect" are basically completely useless.

Try randomly slapping your hands on a keyboard and writing software in <insert language>. Now complain that because you can't do that, <insert language> sucks. That's basically how I see these types of complaints about git.

[alkonaut]

> "oh if you misuse this tool that you didn't bother learning about, it does things you probably didn't expect" are basically completely useless.

These koans point out how the UX of Git often makes it harder (than necessary) to learn.

> try randomly slapping your hands on a keyboard [...] you can't do that

Well it worked when they chose all those command line arugment letters... </s>