Someone in another post mentioned revert. svn revert file == git checkout file, while git revert patches out a whole change. It actually makes sense if you forget about cvs and svn's version of the API.

I saw the word "intuitive" thrown around... http://www.asktog.com/papers/raskinintuit.html

* If there does not exist a branch 'foo', then 'git checkout foo' will reset the file named foo to the head.

* If such a branch does exist, then 'git checkout foo' will move to that branch. You have to say 'git checkout -- foo' to have the first behaviour.

Think of checkout as a local thing to do, and pull/fetch as a remote action.

It can make sense if you do not have prior associations. It is not as if the English language is not terribly abused and ambiguous in our languages. What does "cancel" mean? In linux with CUPS, it cancels a print job. To cancel a process, you have to kill it, but you cannot kill print jobs. Shocking.

What is OOP? How does that definition change between C++, Java, Smalltalk, Lisp/CLOS, and vimscript? How about MVC? What about the differences in GUI lingo between Object Windows, McClim, Gtk, and qt? In other words, you have to learn the language of each different tool you use, and it is unreasonable to expect that it is the same as your other tools.

Aside from that, it is terribly unfair to try to compare svn to git in any meaningful architectural sense; they are completely different creatures that accomplish some of the same goals. git does it better. And it uses different language to describe its new approach.

I have not had a difficult time switching between using svn and git after using both for a long time, except for missing nice features like "git log -p" and "git add -p" when I work with svn. It seems petty to me to quibble over command names.

Those are different projects. Git is one. OO is an abstract concept, we're talking about git communicating to the user, and what level the user must have to understand that communication.

The problem is not that git and svn have different opinions on what "checkout" means, it's that git itself has different opinions on what it should mean.

Again, why is it so bad that we say the interface could be better? Why do so many of those that managed to get a grip on this feel the need to strictly deny that there could be any problem in the interface itself?

Yes, Linus designed it. But he's just human too.

I still have yet to see a single useful advantage of mixing up different meanings in the same word. All I get is "It is that way, learn it or GTFO."

There is a manual... You don't blame a drill press company just because someone thought it was a good idea to use their drill press to pierce their nose, do you? What's the point of providing people with documentation, if you are going to rail on the product for not being 'so easy' that people don't need to read the documentation?

Although, complaining about Ubuntu not doing things the way they "should" is more valid, since Ubuntu is targeted at everyone. :)

Why? The author of a piece of software is under no obligation to satisfy the expectations of its incidental users, especially if he's not selling it to them.

Secondly, in what crazy alternate universe can git, which is given to you free as in libre as well as beer, be compared with IE? If you think git sucks, but still want to use it for some crazy reason, go ahead and modify it to suit your needs.

Lastly, I cannot imagine a world where anyone would be forced to have to cater for a VCS the way we have to for browsers. They're simply too different in function. It's not like you're in danger of being forced into the business of implementing a service supporting commits and checkouts for two different types of repositories on the same source files... unless you work at GitHub. Heh.

The problem here is that there are people telling everybody that "git is easy," "everybody should use git," and then every time someone raises a concern someone brings up the argument above. I wonder, what is your goal? Are you trying to get people who "don't get it" to stop using git? Do you think killing discussions about it will further progress? Are you afraid the interface you learned might change?

The creators of git have created/are creating a modern changeset management tool which, yes, you will have to learn to use effectively. This is a good thing.

Not spending time on completely learning how to deal with an inferior (imo) tool, gives me more time to learn things which matter to me. So it's the exact opposite of "learnt nothing".

Seems that the peasants who have binaries should use rsync manually, instead of expecting tools to do the job.

I suspect these folks were OK with spending hours learning about their DVCS, but for most others, this just seems like unnecessary tedium and frustration, "When can I get back to worrying about the code?"

Someone needs to make the Mac of a DVCS, i.e. one that doesn't require a 20+ page tutorial to figure out, is completely intuitive and "just works."

I currently use Mercurial, and while I don't think it qualifies as the Mac of DVCS's, it seems to be working decently enough so far (for my simple purposes). I could learn git, but thanks to hg-git I'm hoping I won't have to.

Git's user interface isn't perfect, but you're not going to get the "Mac of DVCSs" either. There's a reason for the complexity, doing stuff like merging together the work of three people is inherently complex.

You're not going to come up with some solution that allows the user to "just do it" without also destroying history.

Really? I've got state A and state B. I tell my DVCS to merge them into state C. After reviewing the automatically guessed changes and manually changing the things which could not be guessed, I commit C'. C' is successor to both A and B.

What exactly has been lost / destroyed here?

1. Checkout B. 2. Merge A into B. 3. Git tells you there's a merge conflict and what to do to fix it: "Auto-merging foo CONFLICT (content): Merge conflict in foo Automatic merge failed; fix conflicts and then commit the result." 4. Edit foo and fix the conflict. 5. "git add foo" 6. Commit.

What's the problem?

What I meant to say is that you're not going to get away with using any sort of complex system without understanding what it's doing. This seems to be the sentiment expressed in the original posting, and some of the replies here.

Sure, Git's UI could be improved. But managing several divergent histories and correctly merging them together is a non-trivial problem. If you make a tool that allows the user to just plow on without understanding the underlying paradigm the results are going to suffer.

It's like asking for a RDBMS that allows you to "just do it". You might get away with that for a while, but not for long.

This is a limitation of your imagination. You can write a DVCS that's easy to use and intuitive. Git has an absolutely terrible UI, it borders on idiotic.

One example of a DVCS with a good design and UI is a Bazaar. Sortof like the Mac a few years ago, no one uses it, but I wouldn't be surprised if it eventually gains in popularity. I see two things holding it back right now:

- Launchpad is terrible and needs to be at least as good as Github.

- In concert with having a terrible "hub", Bazaar has a small community of users.

To gain users, it will need to out-innovate like Apple did. That means on all fronts, not just bzr itself but the community, marketing, and the websites that support it.

- Being pure Python it doesn't have the same performance that git does. This may not show up in day-to-day usage, but things like 'convert this svn repo to Bazaar' tend to bring the bottlenecks/performance issues into the light.

- Bazaar made this weird design decision to have two revision numbers. a 'r12345' type revision number that is similar to SVN, but only applies to your local checkout of the repo, and a checksum (SHA1 or MD5) which applies globally (across different checkouts). I think that choosing a revision scheme similar to SVN's but one that doesn't map 1-to-1 with SVN is just asking for confusion from newbies. (I'm not entirely sure why one needs to have local and global revision numbers...)

1. You can abbreviate the SHA-1's in git

2. When you are collaborating on code, it's much more common to use a global identifier so that people can all know which commit is being referenced. It seems like you are making things needlessly complex when you are trying to maintain local and global revision numbers, for little (in my opinion) return. Sure 'r37' is easier to remember off-hand than '5b98d8f' (a shortened SHA1), but if you memorize 'r37' it only means something locally, you'll still have to lookup the global revision id when you want to communicate with others.

Well, hg is nearly all Python (if I recall, their diff algorithm is the only C code) and it's quite comfortably fast. Seems to me that it's a design issue with Bazaar, and not something that one can simply blame on Python.