4 out of the 6 SO most voted questions are common Git issues • Hacker News Board

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

#11

Post by collyw » Thu, May 12, 2016, 11:03 AM UTC

kardos wrote: post #7

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 wh…

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.

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

#12

Post by collyw » Thu, May 12, 2016, 11:22 AM UTC

na85 wrote: post #6

Cpoll wrote: post #4

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 understa…

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.

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

#13

Post by na85 » Thu, May 12, 2016, 11:29 AM UTC

collyw wrote: post #10

na85 wrote: post #5

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…

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.

>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

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

#14

Post by bubuga » Thu, May 12, 2016, 3:04 PM UTC

collyw wrote: post #10

na85 wrote: post #5

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…

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

or

b) download another copy?

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

#15

Post by collyw » Thu, May 12, 2016, 6:48 PM UTC

bubuga wrote: post #14

collyw wrote: post #10

Earlier quoted context omitted.

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…

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)