I wonder how much time and money has been wasted trying to operate Git's confusing UI. The repository format itself seems fine, but I'm surprised we're not all using a better frontend by now.
Let's say you want to write small feature X, and it truly makes sense for X to be a single commit. But doing X involves changing around both Y and Z. Git makes the following workflow easy:
* Fiddle around until you get Y working how you want it
* Stage it
* Fiddle around trying to get Z to work. Try something experimental. Nope, that's not you want it. `git checkout .` Try again.
You don't have to worry about only blasting away the failed Z attempt while preserving Y—since Y is staged, it's easy to keep around.
`stage` is unnecessary if you have a really simple workflow, but it provides a lot of flexibility at very little cognitive cost.
Being able to add bits and pieces to your staging area and then once you've got it all ready commit is pretty useful.
I guess I just don't see the cognitive cost as being particularly high. It's a pretty simple model.
A "staging area" is a useful concept, but it's not one that needs to exist outside the UI of whatever tool you're using to generate the commit.
It's not enough to memorize command line "incantations", you have to understand what's happening.
Git is a sophisticated tool. There are over 100 subcommands!
Once you fully understand the basic terms (e.g., "detached", "HEAD", "branch", "commit", etc.) Git becomes less confusing.
http://www.verticalsysadmin.com/git/flyer.html describes a free webinar we offer on Git basics -- people who have used Git for years come away surprised how much they've learned.
Git allows you to do a lot more than check in and check out. It's a powerful tool for collaborating on source code.
To the extent that one doesn't confront what Git actually is, it can seem mysterious or needlessly complex. There's a method to the madness. :)
You have a widely adopted tool with some real or perceived flaws. Everybody knows them and wants to fix them.
But unless you somehow get mass adoption from the start, the project flounders because everyone will be pointing out that you can't install & use the new tool in restricted environments or on very old environments.
So we're left with the lowest common denominator.
At this point, to break the cycle, either the original developers come with the 2.0 interface and push it hard (which might cause backlash: https://xkcd.com/1172/) or someone with a ton of pull and resources does it from outside (which could trigger a fork or other unpleasantness).
Why the heck wasn't the UI improved back then, before the thing was even released?
I mean, while your explanation is correct, it doesn't explain or excuse the pure incompetence of the original developers when it comes to usability issues. Their laziness or ignorance back then has confused and irritated thousands or millions of developers now, and continues to, and will continue to for the foreseeable future.
Make sure the shit you're going to set in stone is good before you grab the chisel, guys. You're professional software developers, not clowns.
Sorry for the rant.
Personally I prefer the CLI, it's the only tool that I can rely on to do what I tell it to do and to know what's happening. But it takes time and effort to get used to it.
In the same way one can argue whether you call a braeburn a fruit or an apple.
CLI is a subset of UI
The problem with Git (well, one of many many problems with Git) is that it conflates its user interface with machine interfaces-- which means tools that have to work with Git (like those GUI clients) have to use the CLI to do so. They don't have a more powerful option, like an officially-supported API or a shared library they could call into. This is terrible software design.
In fact, there exist many alternative 'frontends' to Git. There are even protocol translators like Hg-Git [2], and many importers that typically use the fast-import format to ingest Git-impl primitives [3]
Separating the UI and machine interface is something that should have been done from day one. In fact, I've been told Git's codebase actually already does that (it just doesn't expose the machine interface to the outside world.) Human beings are not machines. They have entirely different needs.
Chalk that up to the power of fashion and a misguided notion of technical proficiency.
Attempts at different UIs fail because they're all trying to put an abstraction over top of git that doesn't actually reflect the underlying data. As a result, they're limited to the set of git functionality that overlaps their abstraction, and the tools are less powerful.
https://stevebennett.me/2012/02/24/10-things-i-hate-about-gi...
> Once you understand Git's data model, the UI is perfectly intuitive
So it's not intuitive at all.
Not to mention that every damn command is inconsistent with every other command! To remove a file, git rm. To remove a branch, git branch -D. To remove a commit, git reset --hard HEAD^. How is this intuitive, consistent, or even sane?
"I understand git" and "git is easily understandable" are completely different. Git is not easily understandable, at all.
You'd have a better argument with `git rm`, `git branch -D` and `git remote remove`. :)
Note that I never said git is easy to learn, just that once you take the time to understand it, it's actually quite natural and intuitive.
That article you linked is clearly from someone who liked how simple subversion was and is annoyed that git requires more than 15 minutes to learn. But there's a reason almost no one is using subversion anymore.
I prefer powerful and efficient tools that I can use without any learning, since the two aren't mutually exclusive.
> if you just take a couple hours to really try to understand what it's doing and why it's not that hard,
What is it in git's architecture and design that mandates that a file should be removed with "rm", a branch with "branch -D" and a remote with "remote remove"? What about its fundamental architecture makes it so that the commands can't be "git rm", "git branch rm", "git remote rm"?
Nothing, and this is the crux of the argument. Git's porcelain is inconsistent, unintuitive and poorly designed.
> Note that I never said git is easy to learn, just that once you take the time to understand it, it's actually quite natural and intuitive.
What does "intuitive" mean if not "easy to learn"?
> That article you linked is clearly from someone who liked how simple subversion was
Maybe so, but that doesn't invalidate its arguments.
They're not necessarily mutually exclusive, but in my experience there's often a trade off. I would argue that git is about as simple to as it can be without taking power away from the user by forcing an abstraction on him.
> What is it in git's architecture and design that mandates that a file should be removed with "rm", a branch with "branch -D" and a remote with "remote remove"?
Yeah... I have to agree that the choice of command line arguments is the weakest element of git.
> What does "intuitive" mean if not "easy to learn"?
The two often go together, but aren't necessarily the same thing. Something is "intuitive" if the correct thing to do is natural and obvious without a whole lot of thought. Git isn't intuitive before you understand the data model, but once you do, you don't have to spend a lot of time figuring out how to accomplish things, so it becomes intuitive. I would argue that by contrast, subversion is intuitive out of the box, but as soon as you want to do more sophisticated things it becomes rapidly counter-intuitive and very difficult to work with.
I agree with you there. It doesn't mean that things are as bad as "weak tools or hard-to-learn tools", but there's a tradeoff.
> I have to agree that the choice of command line arguments is the weakest element of git.
I think there's a fundamental misunderstanding here. Git's conceptual model is hard to learn, but there's no way around that. If you want to be proficient in Git, you have to understand the conceptual model, and people find it hard and mostly give up, and say that git's core is badly designed (which it's not).
This muddies the waters for people who claim that git's porcelain is badly designed (which it is), because then other people mistake that for the former argument, and we end up talking at cross-purposes.
I think we can both agree that git's core/architecture is great, and the porcelain is quite bad.
> Git isn't intuitive before you understand the data model
I think this meshes with my previous paragraph, but I think git could be much more intuitive (and require much less mandatory learning of the internals for someone to be productive with it) if the porcelain were better designed.
You say that as if the two are mutually-exclusive. They aren't.