[Sir_Cmpwn]

Sad to see this in the grey. Git is unintuitive to those who don't understand it. If you read about its internals and learn how it works, the command line gets much better. It's well documented and it gives you a whole lot of power and insight into the inner workings of the VCS. Things like launching your editor to do more complex commands, plugging a script into git bisect, these are all great design choices.

[viraptor]

It didn't matter how powerful it is. It's still inconsistent and a bad example of ux. Some trivial examples: "tag -d", but "remote remove"; exiting editor after "commit" aborts, but after "rebase -i" continues operation; etc.

There are other projects that interact with git and are really good: tig, for example. But git itself? Someone wrote a good paper about it already. "What's wrong with git?" was the title, I believe.

[exDM69]

All of what you say is correct. git is great in many ways and not too difficult to use once you grok the internals.

But git's user interface is inconsistent, has got weird error messages and confusing terminology with too many ways to do some things.

Good thing that it has quite decent manpages which explain these things thoroughly. The UI gets the job done but it sure isn't a great example of a well designed command line.

[Sir_Cmpwn]

It's rough in some ways, and elegant in others. A bad error message does not a bad UX make. Good error messages are great, but remember UX is also about hitting the important points well.

[open_bear]

There is even a science paper showing that "for most people Git is a magic black box they whisper obscure spells into": http://www.ppig.org/sites/default/files/2014-PPIG-25th-Churc...

[Sir_Cmpwn]

I question this study's sample size and diversity.

Git was made by and made for kernel hackers to support the Linux kernel. It has an expectation that the user understands how their computer works and wants a tool catered to that knowledge. The average web developer writing Ruby or Node in Atom on their Macbook Pro isn't in the target audienece. For someone in git's target audienece, it's a great tool with far better UX than any other VCS - because it gets out of your way and gives you powerful tools for mucking with the VCS to suit your needs precisely. THIS is what makes for a good UX. A tool that's easy to learn is great, but if it can't be mastered and bent to the user's will then I'd rather take one that's hard to learn but accomodating of the master.

[open_bear]

> The average web developer writing Ruby or Node in Atom on their Macbook Pro

It does not matter who it was designed for, git is the de-facto VCS that almost everyone uses today. And people are having trouble using it because there is no better alternative: it is fast and powerful and used by many companies.

But it's UX is terrible: I use git for 10 years and I have to Google every time I need to make a branch tracking a remote one. git reset does different things based on what type of object you pass.

This has nothing to do with knowing how internals work, it is a question of consistency and providing a small non-overlapping set of tools to do my job.

[Sir_Cmpwn]

>It does not matter who it was designed for, git is the de-facto VCS that almost everyone uses today. And people are having trouble using it because there is no better alternative: it is fast and powerful and used by many companies.

It _does_ matter who it's designed for. If someone outside the target audience uses it, then it's not the tools fault for not accomodating them. My point is that the UX is great for those it's meant to be great for.

>I use git for 10 years and I have to Google every time I need to make a branch tracking a remote one.

git branch --set-upstream-to=upstream/master master

Didn't have to look this up. Seems pretty straightforward. Or just git push -u upstream master.

>git reset does different things based on what type of object you pass.

So? I don't see how this is a bad UX. Would you prefer 10 different commands? I wouldn't.

[polymeris]

git has a terrible UI, IMO. git reset, for instance, does like 17 different things. And what does checkout have to do with creating branches as in "git checkout -b"? Not that git branch is that much better, it's conflating creating, listing and deleting under one command (named after a verb or singular noun). Compare to hg's branch/branches or fossil's even clearer convention of noun + action, like in "fossil branch new ...".

That said, you are right that understanding the git model helps a lot and for that, I recommend the "Getting Git" talk. https://vimeo.com/14629850

[e12e]

I personally think mercurial (hg) is much more intuitive than git. Even for use with git, via hg-git[1].

Can't quite put my finger on it, but some subtle differences seem to nudge the user towards more usable workflows than bare git.

[1] https://hg-git.github.io/

[type0]

Thanks, didn't knew about hg-git