[StavrosK]

> Personally I like tools that are powerful and efficient once learned over tools that I can use without any learning.

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.

[nolemurs]

> prefer powerful and efficient tools that I can use without any learning, since the two aren't mutually exclusive.

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.

[StavrosK]

> there's often a trade off

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.