No it doesn't.
I'm not overly impressed with git in terms of it doing the right thing by default. The best options are often sort of hidden away under some option that you have to remember. svn is much simpler and nicer from this point of view in that I don't often have to use flags with it to do the basics.
Perhaps the title could be rephrased as something like: "if git hopes to grow outside the world of early adopters, it probably needs a better interface", although that's not nearly as snappy...
While we're at it... can anyone:
* Comment on mercurial and bzr from this point of view?
* Comment on TortoiseGit?
Most VCSs have a destructive command. If one doesn't expect the destruction from the command, they will no doubt be perturbed.
* You can’t merge upstream changes into your local, uncommitted modifications
Commit.
* Git’s merge conflict resolution workflow is unintuitive
Subjective but I'm curious which VCS has an intuitive merge conflict resolution workflow. I assume this means that without previous experience with the VCS a developer can (immediately?) intuit the workflow.
* Interface for working with the index almost universally confusing
Three switches for a single command. If you want to operate in a business as usual DWIM manner you can just remember --hard.
All that said, I do believe git reuses some commands in a semantically elastic way, sometimes to the confusion of new users.
And the name tips you off that you're about to do something destructive. Like svn's "revert". On the other hand, 'checkout' sounds fairly innocent to me.
> intuitive merge conflict resolution workflow.
IIRC, recent versions of svn walk you through it, asking which one you want to keep or letting you edit the file(s).
I actually use git (the branches are really nice for some things), but I'm considering VC systems for office use, and I'm not quite so sure I'd stick my neck out and recommend git.
FWIW Mercurial now has git-style branches (called bookmarks, hg's branches are different beasts)
It's all a matter of perspective.
I tend to commit lots of incremental progress. I talked to a couple of bzr users who do the same. They insisted that it was important to their project to include these changes that definitely don't compile (e.g. "committing because I'm getting up to go to the bathroom"), etc... in the long-term history of the project because it can help them remember what they were thinking when they were writing the code.
Personally, I do the similar, but I rebase -i before I push and squash and reorder most of that down into small, working chunks that most accurately reflect the real changes to the project.
That is, it's a higher priority to me to say what happened than how it happened. I'm thoroughly uninterested in what the state of the codebase was when you came up with the idea to work on something, how many times you pulled upstream code down, how many times you went to the bathroom, etc... I just want to know when your change went in that affected the state of the project, and exactly what it did.
Theoretically, a recursive merge message would tell me this. In practice, it does not, and the merge diffs don't necessarily show the change that affected the tree, but the delta that had to be applied to resolve conflicts on the merge.
I used to be a gnu arch user, and as such, I used to find it of utmost important to record every minor file save in my permanent history. I've learned since then that it doesn't help me actually understand the project.
Also, the use of sequence numbers (hg has the same problem) causes a lot of confusion. Humans seem to like the idea that there's an easy to understand sequence, but that's false on any project with more than one developer.
Specifically I had this problem with "buildbot try" -- the default implementation does a working-tree diff against the same revno upstream (e.g. if "bzr version-info" says 571, then it uses "bzr diff" to create a patch and sends it upstream against 571). However, if I've committed locally (because...that's just the right thing to do), then it will find either than upstream doesn't have a 572, or it's a different 572. Enter "bzr revision-info -rsubmit:" which introduces network (took 7.49 seconds for me just now) and "bzr diff -rrevid:[long-string-i-can't-double-click].."
I can't tell you all of the exact scenarios that were causing me confusion, but they came down to things like the above.