Hacker News Reader

Comment by sonnyblarney | Hacker News Reader

This is funny, but in reality it's not.

Git is one of the most amazing, powerful tools ever conceived, with one of the must byzantine and ridiculously designed 'interfaces' ever conceived.

People confuse the raw power of a tech, with how well it can be feasibly used. Sadly, due to the later issues, git will only ever be a shadow of what it could have been.

With all due respect to Linus, who'd be the first to admit he's not very good at UI stuff (I mean command line as well)... it's truly a sad thing.

This is a major 'problem that needs to be solved' I'm interested to see how it could evolve into something 'better'.

View on HN

I don't think the complexity of git's command options is a UI problem. It results from the basis of its operation. We could change some names, add or remove some concepts to how some of the operations are performed, but there are simply a large number of actions to handle many edge cases.

A better solution for prose was to always be merging with live multiple collaborator updates. Conflicts are visible in real-time. I can't see something like this would work with code. Hmm interesting... unless we only allow additions and refactorings to working checkpoints.

Yes, I don't really understand all the people trying to "fix git". Git's fine, though the complexity makes it challenging, especially for new users. However the complexity is a direct result of useful features. "Keeping it simple" is great, except when the complexity is needed. I'm hard pressed to name any features I could do without.

There are two problems: one of inherent complexity, one of UI.

First - the UI is a mess, and that should have been fixed. It would make a big difference.

Second - is the inherent complexity. That's a good point, but I feel many things could be hidden or obfuscated.

Most poignantly, Git does something that most of us do not need: it was designed to work as a 'completely distributed system', i.e. for open source.

Almost none of us do that. 95% of uses cases related to you and I working collaboratively, on a project together.

The need to have repos which are essentially totally distinct from one another is a huge source of complexity and it simply doesn't need to exist in most cases.

So Git is basically an 'admin level tool' that is commonly used in scenarios for which it wasn't meant to be used, with a confusing interface.

It's costing a lot of time and money and headaches, I do believe someone may come along eventually and fix it.

This thread is essentially evidence of this - see how many people have difficult teaching what should essentially be a simple thing in most cases.

Way too many very smart people still spend too much time clustering around in git.

Ever used a centralized VCS, such as SVN? That seems to be what you want? A distributed VCS is extremely useful, for mine and many others' uses, however.

>I'm hard pressed to name any features I could do without.

Nobody is complaining about there being too many features. People are complaining about the arcane incantations that one needs to conjure to call them.

Good point. I wouldn't say nobody though. There are people out there that think there are too many commands. I've even seen academic papers that claim the staging area is problematic. I love the staging area, and don't think it's terribly confusing; there's always commit -a if you don't want to use it. It does lead to some confusion, but it's worth it for the added features.

That's just one example, but there definitely are people that think git's too featureful. As for more valid criticisms, I'd agree. I've heard the CLI compared to being in an abusive relationship. All that said, I can't really think of a better way to handle things without losing useful functions. In which case, I don't have any better ideas, and don't really know what I'm criticizing.

Reply on news.ycombinator.com