> If its interface is not simple and elegant, I don't see how you can call git simple and elegant, since it's how all users will interact through the interface.

At least in my experience, the interface makes a lot more sense if you understand the underlying data structure, which does have a certain elegant simplicity. (Even if it doesn't work quite the same as traditional source code control systems. Failing to work with directories is a problem of the git approach. Having a nice offline story is a distinct advantage.)

> And personally I prefer a VCS with less ways to shoot myself in the foot than git.

Oddly, the thing I love about git is how easy it makes it to recover from mistakes. Even if there are more ways to shoot yourself in the foot, there are also more ways to put your foot back exactly the way it was before you shot it. (If only real life worked that way!) This is what the immutable content storage under the hood of a git repository gets you.

If you know the commit hash (and there are a bunch of ways to easily keep track of these), you can get back to the state that's represented by that hash. Commands like merge/rebase/cherry-pick make this particularly easy by providing an '--abort' option that means "I've screwed this operation up beyond repair and need to bail out." And the abort works. As long as you had your target state committed, you can get back to it. (And if that's just a transient state that you don't want to persist, it's easy enough to squash it into something coherent.)

>the interface makes a lot more sense if you understand the underlying data structure

Except that I don't have to understand the underlying data structure to use a more basic VCS like Mercurial. What makes git so special that I would have to do that before being able to use it?

And for recovery from mistakes, I meant stashing the changes somewhere, deleting the repository and downloading a clean copy to start again, which I had to do a few times with Git and never with Mercurial (I might had to do it once or twice with SVN, though).

> Except that I don't have to understand the underlying data structure to use a more basic VCS like Mercurial. What makes git so special that I would have to do that before being able to use it?

I don't think it is special. Generally after a while using a given tool, library, etc. I find it useful to dig in a bit and see what's happening under the hood to help understand why it works the way it does. git just happens to be the tool under discussion at the moment.

> And for recovery from mistakes, I meant stashing the changes somewhere, deleting the repository and downloading a clean copy to start again, which I had to do a few times with Git and never with Mercurial (I might had to do it once or twice with SVN, though).

I think we're talking about the same sort of mistakes. It's hard for me to imagine a case where you'd need to blow away a local git repository entirely. Worst case scenario, there should be good refs available in a remote that are just a 'git fetch' away. (If there's no remote, then blowing away the local repo is essentially just starting from scratch anyway.)

You also don't have to understand the underlying structure for a similarly powerful DVCS like bitkeeper. Yes, it isn't open source, but git was a major step back in usability for my group from bk to git.

Yes, this. I actually tried bk before git, and actually used bazaar and then mercurial before git as well. I was stunned at how arcane the UI in git was made (And how arrogant the community of users around it could be, too). Bk was clean and elegant frankly. I'm no idiot when it comes to the concepts -- but git's CLI interface is just awful.

Bitkeeper is in fact open source now, BTW. Too late, but it is.

You're right. The arrogance was hilarious. People with no experience with bk saying, "What's your problem?" Now, git is super fast, because its core is written by Linus, but I think he is just so much better technically and so far into the internal weeds of Linux for so long in so many areas that he had trouble creating an API for mere mortals.

> git was a major step back in usability for my group from bk to git.

What does that mean in concrete terms? What are the failures you're seeing with git that you weren't with bk? How long has your team used git? bk?

We used bk when I was with the group for 3 years and then switched to git. Been using git for 8 years. I know git, but the ergonomics and basic English semantic meaning of commands is much worse. I have to look up git commands and subflags _all_ the time still for checking out old versions of files to a new file. Looking at tags. Commiting to a new branch, et c. Bk's version of gitk was superior and the usage was nicer. I've used mercurial, svn, cvs, git, and bk. Git is hard, but it is the standard now, so of course I'll continue to embrace it. Just not as ergonomic.

> At least in my experience, the interface makes a lot more sense if you understand the underlying data structure, which does have a certain elegant simplicity.

Yeah. Take an afternoon to read through gittutorial(7), gittutorial-2(7), and gitcore-tutorial(7). Git is a tool, and just like any other tool (car, tablesaw), you will be much better off if you take the time to learn to use it properly. Once you see "The Matrix" behind Git, it becomes an incredibly easy to use and flexible tool for managing source code and other plaintext files.

The fact that you put Git in the same category as tools having a potential of inflicting grievous bodily harm if misused is telling. And why does Git require this whereas other VCS don't? Mercurial was incredibly easy to use nearly right out of the gate, not after an afternoon of work.

> The fact that you put Git in the same category as tools having a potential of inflicting grievous bodily harm if misused is telling.

They're just examples of tools.

> Mercurial was incredibly easy to use nearly right out of the gate, not after an afternoon of work.

I talk about this elsewhere in this thread, but I disagree with this assertion. I find Mercurial baffling and Git very elegant, though it could be an artifact of the order in which I learned the tools.

> And why does Git require this whereas other VCS don't?

It doesn't. It just works better when you take the time to learn how it works. (Which is an experience I commonly have with the tools I use, for whatever that's worth.)

Agreed. If the applications we built using git were as awkward as git...our users and clients would scream, or worse.

I don't understand the relevance of git in all of that

You can almost always recover from your mistakes with git reflog.

Yes and no. I'm a git guy and a fan, but you can really, really mess things up. Usually, this is only when using features like force push; however, there are arguably legitimate use cases for that.

Buddy had a teammate that almost force pushed references from a slightly different repo. What a mess that could have been! I agree regarding the usefulness of reflog, and think the complaints about messing things up with rebase, reset, ect are overblown. It really isn't an issue for intermediate users.

Hence almost always. It’s not a common situation to delete commits from history, etc.

I don’t see the capability to force push as a negative. There are situations in which it’s necessary, like forcibly removing history (something I had to do just today).

Git gives you the ability to shoot yourself in the foot, so it’s up to the operator to not make a mistake like that without backing up the repo to a different place first, etc. Something something only a poor carpenter blames their tools.