[balabaster]

Git isn't really terrible software. Git is really powerful and quite brilliant in many cases. However, the user experience sucks. Sourcetree went a fair way to take the pain out of it and have largely done a reasonably good job. Again, it has its shortcomings, lord knows we could do with a nice easy wrapper that takes the sting out of nagivating Git and walking us through the work flow better than the current system.

If you wanna drive stick, you've gotta learn how to use a clutch and gearshift. You can't expect all of the power without being willing to put in some sweat equity to learning it.

[shreve]

TL;DR: Git really _is_ terrible software.

You're defending VCS in general. Git is a single VCS implementation, and a shitty one at that.

Git is hacked together from C, Shell, Tcl (which tbh, I've never even heard of), Python, and C++. Mercurial, by comparison, is Python and C.

Git has an awful UI out of the box. Why? There's no reason other than fuck you. Mercurial's UI out of the box is similar to every project that has tried to make Git easier to use. It's for _people_ to use, not Linux kernel developers. [Humor on this topic: http://homes.cs.washington.edu/~asampson/blog/git.html]

Git's documentation also sucks. Suppose you don't understand rebasing. Try running `git help rebase` and you'll get this back: "git-rebase - Forward-port local commits to the updated upstream head". WHAT THE FUCK DOES THAT MEAN?

Another example: `git help push` returns "git-push - Update remote refs along with associated objects". Why is this so goddamn complicated? It's almost like it was written by developers that have no idea what it's like to not understand how git works. Oh wait.

Mercurial on the other hand, has simple explanations at first, with more in-depth explanations if you look further. `hg help push` returns "push changes to the specified destination". Which is how someone would explain VCS pushing to another human being.

Linus Torvalds isn't running `git help`, people that don't understand git are. Documentation should be written for them.

[alsdifu3]

All this comment says is that you don't understand git and seem unwilling to try. Millions of devs use it everyday and seem to like it.

[balabaster]

I think "like" might be a strong word :P No compelling alternative is probably closer to the truth :D

[bronson]

You could have a decent point but your combative tone makes it sound like you only want a flame war.

> Git has an awful UI out of the box. Why? There's no reason other than fuck you.

Lovely.

[shreve]

Excuse me, Git gets me riled up.

[structural]

One of the reasons that there's not a "nice easy wrapper" that you refer to is that the workflow of using git is very, very different depending on what your role in a project is.

When most people talk about the git workflow, they are thinking of the workflow of a feature developer - which is one of the simpler use cases. Let's think about git, however, as a tool for automating existing workflows, though:

Person #1 is a developer. His workflow looks something like "git fetch public; git checkout -b new-branch public/master; $EDITOR; git commit; git push incoming new-branch". His 'incoming' remote goes to a repository of everyone's unreviewed feature branches, and each feature is parented from the last commit that was in the public repository.

Person #2 is a reviewer. He has two remotes, "incoming" and "reviewed". His workflow is "git fetch incoming; git checkout incoming/branch-to-review; git log --stat; $VIEWER; git push reviewed branch-to-review"

Person #3 is an integrator who's responsible for the state of the 'master' branch on the 'public' repository which is visible to everyone. He only wants to merge reviewed branches. His workflow is "git fetch reviewed; git checkout master; git merge reviewed/branch1 reviewed/branch2 reviewed/branch3; $BUILD_AND_TEST; git push public master".

This is the sort of real-world use of Git that goes on in large organizations. It's actually harder to think about using Git in a single-developer project, because one person is playing the role of developer/reviewer/integrator, and typically doesn't think consciously about what role he's in at any one point in time: so his workflow is sort of a mix of all of the above, which ends up being overly complex.

Tools like SourceTree really don't help the situation either, because they try to give you a graphical interface to git commands in general (since they don't have any insight into the development process for a particular project).