4 out of the 6 SO most voted questions are common Git issues | Hacker News Reader

4 out of the 6 SO most voted questions are common Git issues

stackoverflow.com

11 pointseridal14 comments

Part of the fault lies with the documentation, and with the way git communicates with the user.

For example when I was learning how to use it I routinely had to Google for many tens of minutes to answer questions such as:

What the fuck is "fast forward" and why is git displaying that message?

What are "refs" and why would I want to update them?

What is HEAD? Why isn't it named something more intuitive?

Etc. Why did I have to Google around for it? Because the documentation didn't actually answer my questions.

It's all compounded by the way the documentation is written: namely, from the perspective of the user who is intricately familiar with how git works. You have to remember the silly and needlessly obtuse names for everything. Why is there no "git-undo-commit"? What the fuck does rebase do? Bisect?

I realized writing this that even though I have undone commits in the past, I don't actually know how to do it. I just Google it every time.

It has the advantageous position of being better for certain workflows than CVS or mercurial perhaps, but frankly git is just not a very good piece of software.

The problem to me seem to be that Git is too powerful. It has many features built in and my guess is that the average dev uses a tiny fraction of them.

https://xkcd.com/1597/

The XKCD comic is true, because for most people downloading a fresh copy is far easier than working out how to use git properly.

> The problem to me seem to be that Git is too powerful. It has many features built in and my guess is that the average dev uses a tiny fraction of them.

I don't understand why that is supposed to be considered a problem.

Everyone has their personal itch, and scratching that itch is more than enough to actually do your work.

No one needs to memorize a whole dictionary before getting to speak with someone.

> The XKCD comic is true, because for most people downloading a fresh copy is far easier than working out how to use git properly.

If a local repository is broken, would it be better to:

a) spend hours trying to debug it, pinpoint the problem, come up with a solution, pray it doesn't affect remote repos

b) download another copy?

Depends on the circumstances.

Need a fix in the next hour option a)

You are going to be working with a large team on a long term project, no deadlines are immediately pressing option b)

>because for most people downloading a fresh copy is far easier than working out how to use git properly.

A true and stinging indictment of git's poor ui/ux

> Etc. Why did I have to Google around for it?

Googling for something is more convenient than going through the man pages, and Google is awesome at providing you with the best content associated with your query.

The highest voted question regarding git, «how do you undo the last commit», is the very first example listed in git's man page on git commit.

Convenience always trumps availability.

What we need is a GUI app for controlling git. Something that lets users drag and drop branches, and click undo, fix merge conflicts, etc, without having to use the command line. It would draw two commit trees, one local, one remote, and the common parts would be in one colour and the differences in another, etc. Basically make it /extremely/ intuitive and remove the need to know the command line.

(Also it can say what it's doing in command-line form, for those who want to learn it and move on from the GUI).

I didn't do an exhaustive search, if such a project exists please point me to it. GitHub's desktop app is a start but it does not fit the bill, same for git gui and gitk.

Eclipse / Pydev have at least two of these available (for some reason different project I have use different graphical git plugins).

They are nice for the easy stuff (push, pull, create new branch), but the simplified menu of command means that I don't actually know what git command I am executing if I select some of the options. As a result I stay away from them.

> What we need is a GUI app for controlling git.

Why?

I mean, I don't oppose anyone investing his own time developing yet another GUI interface for git.

But the thing is, a command line gives you much more control and is actually quicker to operate than any GUI app.

The git questions are really simple, almost at the level of "how do I hello world in X?"

I think this is more indicative of the level of git adoption than any complexity - and don't get me wrong, git is complex and messy.

I also think git gets a lot of these questions because developers want it to just work, and it doesn't. People who normally happily spend days figuring out a framework but are resistant to understanding the git mental model. Compared to other version control, the 'basics' are an order of magnitude more complex, and without an understanding of the internals, you will have a bad time.

A source control tool really ought to just work. I want to spend my time doing productive things, and not wrestling with arcane tooling.

This exactly what I think when people suggest removing code comments and keeping them in git commit messages instead.

Git is powerful, but it's a pain in the arse to use. I would rather be concentration on code problems rather than having to work out how to use the tooling. I am sure the majority of developers don't actually need a distributed VCS (Github is popular as a centralized place for it after all).

Surely this is an indication of its popularity?

Reply on news.ycombinator.com