Comment by aequitas | Hacker News Reader

Comment by aequitas | Hacker News Reader

My collegae told me I'm the guy with his phone number in the git.txt file, don't know if that's a compliment?

But whenever I try to explain Git to someone I try to step away from a computer and just work out the problem on a whiteboard. Using post-it's for branches/HEAD/tags and marker to write down the commits and the commit-tree. Preferrably permanent marker to reflect the permanent nature of commits with regards to branches (eg: rebasing keeps the original commits around). Also I ditch files in favor of a picture of a cat there changes are attributes like added body parts or toys since most people like cats better than files.

Taking it away from a computer really helps to reduce the complexity involved and thinking about what manipulations you make to the Git 'database' visually really helps understanding the concepts imho. Just going through it step by step as if you where the Git binary making the changes, and after a while the Git commands turn from hard to remember trivia to tools in your toolbox.

Conversely, this is a massive indictment of the git user interface.

People used to talk about "CASE tools": Computer Aided Software Engineering, by analogy with the CAD tools that replaced physical drawing tables once the technology got good enough. I joke that certain tools are "computer impaired software engineering", and git can certainly belong in that category at times.

What we have built is a tool with a good internal model but a user interface that it's easier for you to not use a computer, to step away to the whiteboard, in order to work out what to do.

We don't tolerate this for, say, word processors; people don't go to a piece of paper to lay out their headings and only then work out the incantations necessary to achieve that result.

(Has anyone attempted to make a "transparent porcelain" GUI which represents the "intuitive" internals in an actually explanatory way? The success of which could be measured by the reduced number of mistakes and amount of apprehension experienced by non-expert users?)

Very true. But the word processor example is a little scewed. It depends on the audience and the value they want to get from the tool, take Latex for example which is widely used writing scripts, being far away from WYSIWYG.

Have a look at Gitless[0]. It's a layer on top op Git which simplifies/rearranges some of the concepts and commands of Git while still manipulating the Git DB in the same way (you can switch back and forth between Git and Gitless seamlessly).

[0] https://gitless.com/

> We don't tolerate this for, say, word processors; people don't go to a piece of paper to lay out their headings and only then work out the incantations necessary to achieve that result.

There's a reasonably significant set of people that do this sort of thing. The backlash against word processors in favor of simpler focused writing tools or even simpler word processors is what I'd offer as evidence. Scott Hanselmann's video series on "How to REALLY use Word." is another example. (Word has offered powerful stylesheet features since at least 1991 and very few people actually use them, even those that could benefit.)

I don't think it's an indictment since it's a clear tradeoff. Yes git isn't intuitive or self explanatory for newcomers, but that's only because it's optimised to be maximally efficient for experienced users.

To me, this is a sensible decision. The target users of git will use it day in and day out for decades, in this case it makes sense to prioritise experienced usage. For onboarding new users there are plenty of good tutorials, and I think in the long run it makes sense to put the legwork in with those, rather than switch to a more intuitive but less efficient porcelain.

I disagree. Git is complex solution to a complex problem (collaborative code management), so it's understandable there are complexities in mastering Git. However the UI of Git just doesn't make sense in some area's, especially to a newcomer. For a lot of people it's enough to understand the basic concepts with commands that make sense. But as it is right now the UI turns this in to hard to remember concepts and command arguments that belong more in a trivia quiz than a user guide. Also see: https://gitless.com/#research

> Yes git isn't intuitive or self explanatory for newcomers, but that's only because it's optimised to be maximally efficient for experienced users.

But that implies that a trade-off has to be there, which it does not. If you design your features well, it can both be quite intuitive for newcomers while still affording efficiency for experts.

A great example is the staging area in git. It is a horrible feature, that causes lots of interactions with other commands that are inconsistent and unclear, especially for newcomers. How to do it better? Just make the staging area a full-fledged commit. Considering that it's already pretty easy to edit a commit anyways, promoting the workflow of just polishing a commit before publication is more intuitive for users, and it means questions like "how do I see what the diff of the staging area by itself is?" is really just "how do I see what the diff of a commit by itself is?" One of those questions I already know the answer to, the other I don't.

It is encouraging with the work going into the `git checkout` split into `git switch` and `git restore` that there is growing pressure among git developers to make things more consistent for users and smooth over some of the roadblocks, including some of the confusion between the staging index and the working directory.

Mercurial solves the same problem but does it in a much more intuitive fashion without compromises for power users. Saying git is optimised for power users is just after-the-fact rationalization of git's horrible UI.

it's optimised to be maximally efficient for experienced users.

Except it's not. It's an ad-hoc accretion of overlapping functions with unintuitive naming. An attempt is being made to rectify this with the "switch" command, but it's a long way from being optimized for anything at all.

We certainly tolerate it for word processors, it is called LaTeX, and a majority of CS papers are written in it. It is pretty complex, and you sometimes need a help of outside expert, but I cannot imagine using Word instead for complex documents. One you get past the learning curve you can be much more productive.

Hm.. replace a few words and you will get a paragraph about git.

In my experience, the only advantages LaTeX has over Word are mathematics typesetting and being able to be checked into source control. Word has a fair amount of powerful features for document layout, that are often much more easily discoverable than LaTeX (although there's no indication that "Replace All" means "replace all in selection" if you've selected it).

Word certainly has a number of powerful features, but every time I use it, I find it is really hard to have your document look consistent.

In LaTeX (or Markdown, or some other markup), it is pretty easy to enforce common style: font name, font size, indentation, space around figures, and so on.

In Word, not so much -- one bad copy-paste, and your document has a few words in unusual font, or "11.8" pt characters, or "1.17" line spacing. This is especially bad if you are working together, and some of your collaborators are using non-English language -- you see a mix of "Heading 1" and "Titre 1", each configured separately.

I am pretty happy that now that I am not longer in academia, I don't need to deal with either Word or LaTeX -- it's all Markdown, JIRA's markup or, in the extreme cases, Google Docs. Still, if I had to produce a fancy looking document today, I'd probably go for LaTeX with a GUI like Lyx -- good discoverability, and pretty clean .tex files on output.

Reply on news.ycombinator.com