Comment by na85 | Hacker News Reader

Comment by na85 | Hacker News Reader

Parent Full thread

Git's UX is horrible for people who don't know git, i.e. git beginners. All the documentation and error messages are written as if the user is already intricately familiar with the inner workings of git. As a result, it's very hard to learn because you don't know what you're about to do without hours of googling cryptic error messages.

Perfect example that happened to me today:

    $ git push
    fatal: The current branch insert_branchname_here has no upstream branch.
    To push the current branch and set the remote as upstream, use

    git push --set-upstream origin insert_branchname_here

What does it mean to "set the remote as upstream"? That phrase makes no sense to me. Is that going to overwrite master on origin? I have no idea, but I'll be damned if I am going to hit enter and risk overwriting my upstream branch, so I Ctrl+C out of there and had to read a bunch of awful reference docs posing as a tutorial.

Git is just plain terrible in almost every way. It just happens to be less terrible for certain workflows than CVS/SVN/mercurial/whatever.

To save you some time and unhappiness:

Yes, git’s UX is absolutely terrible. It is an abomination. It is the worst command line tool I’ve extensively used in that regard. For a long time I stubbornly used mercurial, which is vastly superior.

But, it has become a de facto standard. This is a tragedy. But it is a fact.

So it is best just to spend time learning it, find a subset of commands and make a cheat sheet you can refer to, and accept that the world is imperfect. Hopefully at some point in the future git will die and we will transition to the next big thing, and they will get it right that time.

There are many such things in the world of tech, and in most cases it is best to say “yes, it’s awful, but no, I can’t change it, and rather than expending energy on hating it (which is totally justifiable) I will expend the energy on minimising its damaging impact to my productivity and focus on accelerating my work elsewhere.”

I say this because I have spent so many hours ranting about git and every time it gets in my way (git submodules anyone?) I used to get so stressed by its design that it would hurt my productivity.

Be the Zen Dev: acknowledge it, isolate it, keep it at arms length.

Tips: Make a cheat sheet, use a minimal feature set, don’t try to do anything clever with it, and always have a way out (eg backups! Take copies of your directory before dealing with lesser know commands! Try things out on dummy repo’s before breaking your own, etc.).

> This is a tragedy.

I don't think it's a tragedy. UX can be fixed (even if difficult because of backwards compatibility and social concerns). Changing the underlying technology is much harder.

git has become a de facto standard because it gets everything else right.

> But, it has become a de facto standard. This is a tragedy. But it is a fact.

I feel this sentiment so often in this field. It’s really distressing.

Are you familiar with "worse is better"? Sometimes what makes a technology a pain to use is also what makes it competitive.

The command failed, with a clear error message, and a direct instruction on exactly how to redolve it. That is good UX.

Your example boils down to not knowing the word "upstream". I would argue that is table stakes domain knowledge for decentralized version control, and is trivially easy to search for. That does not make bad UX.

Good UX does not eliminate the need for domain knowledge, it eliminates incidental complexity from a user's task, and one could argue makes a tool pleasant to use.

I don't disagree that there are rough edges to git (the debate over merge vs rebase is a glaring example), but "just plain terrible in every way" is gross hyperbole.

Sorry but if the error gives you the right command to run first time then it should just run it first time by default. Sane defaults for new users is good UX. Not an error telling you exactly what command to run instead. It already knows what you intended, for Christ sakes, because it's telling you what you should copy and paste instead!

It's not necessarily always the correct command to run, it's just suggesting what you probably want to do.

Which should be the default, based on popular use. You can always use the command it suggests to do something different.

Well considering how many people who now know git and understand it, it doesn't make sense to do that necessarily. Rather they should make it a configurable option which do now see push.default (https://git-scm.com/docs/git-config)

Right, which means changing it will harm the UX due to ingrained pattern. That's not what I'm arguing for.

I'm arguing against the idea that showing an error message with the exact command to use is good UX - see the original comment. It is not.

But it doesn't know what you intended. It's guessing. The consequences of guessing incorrectly could be very, very bad, as you are pushing your code to a remote host.

Again, the whole point of git is that it is decentralized; there is no requirement that you have one single central server that you are pushing to; there could easily be multiple places that you might want to push something to.

Using something as default that makes sense for a centralized VCS when git is not centralized is, imho, worse than bad UX, as it teaches incorrect assumptions.

Again, this is table-stakes knowledge for using decentralized version control.

I don't know. I've gotten away with using pretty much the commands in this guide for almost three years now (professionally): https://rogerdudler.github.io/git-guide/ - I even structure my orgs internal git documentation around these commands for newbies (with sources of course).

There are times when you need to troubleshoot a few things but most of the time you can just delete your local repo and reclone it - easy peazy. One of the other great things about git is that even if you do somehow fuck something up upstream it is really easy to get it back. Heck I think git is pretty awesome.

Have you tried the official GitHub client? I've worked at a few places where non developers started to use it because the ability to collaborate through pull requests has so much benefit outside of development. I'm a huge fan of IntelliJ and use the inbuilt git client most of the time, it abstracts most of the complexity. Sourcetree is another good product.

Reply on news.ycombinator.com