
4 out of the 6 SO most voted questions are common Git issues - eridal
https://stackoverflow.com/questions?sort=votes
======
na85
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.

~~~
collyw
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/](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.

~~~
bubuga
> 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

or

b) download another copy?

~~~
collyw
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)

------
kardos
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.

~~~
collyw
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.

------
Cpoll
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.

~~~
na85
A source control tool really ought to _just work_. I want to spend my time
doing productive things, and not wrestling with arcane tooling.

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

------
collyw
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).

------
alblue
Surely this is an indication of its popularity?

