Hacker News new | ask | show | jobs
by SOLAR_FIELDS 3447 days ago
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.

1 comments

It's well designed in terms of the underlying concepts and functionality, which are (mostly) brilliant. Its user interface is a landfill fire.
> 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"?

Can you give a succinct definition of what `git add` and `git checkout` do without relying on documentation?
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?

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.
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.
I see you failed yet again to provide any example to substantiate your baseless claims.
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.

This is the most obscure command mentioned in the article:

    git rev-parse --abbrev-ref HEAD