Hacker News Reader

Comment by dividedbyzero | Hacker News Reader

I feel like not having a git for human consumption is a huge missed opportunity, and I do hope something like that will arrive soon-ish. People in software development seem to not realize at all just how abysmally awful git's UX really is. Explaining git to a non-developer person who just wants me to assist with a python issue always feels a lot like explaing thermodynamics to someone who just wants to boil a kettle of water; yeah, sure, not interested, I've just sent you the file by email, please have a look.

I feel like making collaboration less painful has been the greatest innovation driver in the last few decades, and has paid off absolutely enormously. Imagine where a git/Github for other disciplines could take us. Given software developers build such tools, and given software developers overwhelmingly know how neat git really is, it's actually kinda strange that there's still such a dearth of good solutions in this space.

View on HN

I'm like that. My own way of working involves files in folders and old versions of anything are overwritten or deleted. If they still exist it indicate an unfinished job. I don't keep draft versions of letters and emails either.

I would love to collaborate but when I start looking into git the amount of stuff I don't fully understand keeps growing. I should want something in my work flow that I don't understand? If it stops working just like that, the way everything seems to, I'm suppose to fix something that I don't understand?

When trying to figure out how it worked I read discussions from truly experienced users who decades into the process apparently still had to learn now to unstuck themselves.

I'm not saying its bad at what it does. Its much worse, I have no idea what the point is. It seems tailored to manage top of the developer pyramid issues that I imagine to be hard enough to justify its existence.

In applications I've seen copies of data get modified in different places then merged back together again. Its a horror movie!

> I have no idea what the point is.

As a lone developer, it lets you easily snapshot the state of your code at appropriate points and then compare those to the current state to find out what you broke. Of course, you can also do this by making copies manually, but that gets complicated if the program consists of more than file.

The real benefit is when you have more than one developer working on the program. If you make some changes on your machine, and I make some changes on my machine, and when we're done we want a single unified version of the program (with both your changes and mine) in order to deploy it, what should that look like? If all we can see is that line 123 in some file is different in your version and my version, how do we know which version of that line we want?

Git keeps track of (in the form of a graph structure) the fact than your version 1 is a descendant of our original version, your version 2 descends from your version 1, my version 1 descends from the original version, and so on ... and when we merge our versions, we get a final version that descends both from your latest version and mine.

You could do all this bookkeeping manually and figure out what to diff against what, but git gives you tools to work with.

> Of course, you can also do this by making copies manually, but that gets complicated if the program consists of more than file.

...and manual copies don't offer you the great automations that git provides you for free, like being able to tell when exactly each line has been changed last time (so you can check the whole context of how and why that change was made) or perform a binary search of a revision that introduced a bug. Even when working alone, these tools are invaluable.

To me, this is mostly a solved problem for casual contributors using the web interface of GitHub (and I assume gitlab, Bitbucket, and others). If more "serious" contributions need to be made, learning the basics of how git works isn't that difficult - branching, commits, and merging are basically all that a novice user needs to understand, and they're pretty easy to explain concepts (even if it means you're telling White lies about how it works under the hood).

We don't expect the average person to understand the tools and workflow of a mechanical engineer working with SolidWorks PDM - we shouldn't expect the average person to understand git (which is basically the software equivalent). I've never disagreed with the arguments that git is confusing or difficult to learn for non-software-developets, but I've never really understood why that's a problem.

I like to think of Git in analogy with cars.

Everyday folks aren't expected to know how their car works, much less tinker with it. Not the enthusiasts, who will find a way to grok the full specs of cars and tinker even if you tell them not to.

Normal everyday folks should be content leaving the gory details to their mechanics. I'd wager it to be the same with Git, as an everyday tool of software engineers, rather than that of layperson. This is not gatekeeping; it's a fact that Git is not your usual point-and-click stuff and UIs that attempt to do so can only simplify it so much. Real enthusiasts can always learn how to use Git if they want to, there's no need to make it simpler or easier for the 'casuals'.

The fact that people even have trouble with self-descriptive software like Microsoft Word - which is probably, in terms of UI, one of the easiest, most accessible UIs ever with years of research and iteration - speaks to the fact that not everyone will 'get' Git, nor sho uld there be a need to please or try to reach to everyone with a software that has as many complicated features as it does for the multitude of engineering problems it tries to solve.

Reply on news.ycombinator.com