Live data from Hacker News

Oh Shit, Git

ohshitgit.com

81–90 of 237 posts

Re: Oh Shit, Git

#81
post #74
post #33

Earlier quoted context omitted.

I'd argue the opposite - that the model was so good and so much better than anything else that it was adopted despite the UI/UX flaws. Things can be good, have a flaw and still be considered good. That doesn't mean that we pretend the flaw doesn't exist.

Mercurial is built on what is almost the same model and has what I think is a better UI/UX. Some people say that git is technically superior but you really need to be an advanced user for it to matter, or work on a really large project. At work, we switched from SVN to Mercurial, and from Mercurial to Git. Most people were happy to switch away from SVN, but few enjoyed the change from Mercurial to Git. Personally, it…

I was also a Mercurial fan who had to reluctantly accept the rise of Git. Git was always a bit quicker, but Mercurial was much more predictable until you really understood the ins and outs of Git.

> Why Git came to dominate and not Mercurial?

The answer is actually really simple and non-technical: Github. We take these feature rich online code hosting platforms for granted now, but Github was really the leading edge of the wave. It made it easy for people to work together on writing software so it had great takeup and started a Git snowball effect.

Re: Oh Shit, Git

#82
post #45
post #4

Git is a reminder why even the best minds in software development sometimes really should talk to UX/UI people.

Git's UI/UX is one of the worst engineering sins to be committed in the last two decades, and this website shows why. Literally nothing about git is intuitive and the "underlying model" is entirely ad-hoc. Instead of celebrating how Linus built git in only a few days he should be castigated for knowingly setting up ill-conceived software to go viral.

Git is fast. And turns out that's a fundamental feature for good UX. As a user you can learn a complicated UI, but you can't make a slow UI fast.

(FWIW, I don't consider git complicated and I'm far from a power user)

Re: Oh Shit, Git

#83

My mental model of a git repo is basically a bramble bush with labels on it. The bramble stems and branches are the commit history (which may join and well as split, unlike a bramble). The labels are stuck to particular bits of the bramble. Some labels are even stuck to other labels! You can move the labels around, and you can glue extra bits of bramble to the tips of what you have. You can even hack about with the b…

Learning the underlying model behind git is well worth the effort. For me watching Steve Smith's talk - Knowledge is Power: Getting out of Trouble by Understanding Git - was a lightbulb moment. Here's a 2019 presentation of that talk. https://www.youtube.com/watch?v=fHLcZGi3yMQ

I think this is what can confuse people. We have to face the facts that not everyone will need or be able to grok all of what goes on in git and what makes the car go forward. We can all drive that car still!

Take the recursive merging stuff around minute 39. Do I need to know why git's model for merging is so much better and how it works its magic? I don't think so. It's an implementation detail.

Do I need to know how a gearbox works to drive stick shift?

I have never thought of git as a bramble (tree worked fine for me :)) but the thing I always tell people about too is the labels part. What I think is enough for people to realize is that it's just like say SVN or CVS or any other source control mechanism in that there's a tree (bramble) of commits and then every commit can just be pointed to by a label. I can move those labels around any which way I want. Everything else follows from that on a surface level that is the only thing required to work with git in most situations, including some advanced ones.

You don't need to know why certain operations in git are faster, better, have less conflicts or how they work internally. You just need to know what they do and when to apply them.

I don't need to know why I can't make my car start or switch gears without pushing down the clutch. I just need to know when to push the clutch, i.e. if I want to start the car, push it. When I want to switch gears push it (well, mostly, on cars you want to last a while still lol). Of course some people won't even be able to learn how to drive stick shift and can only ever drive automatic.

Re: Oh Shit, Git

#84
post #39

I've long considered git to be a wrapper around cvs designed to make me feel stupid.

I liked CVS/RCS and still use RCS for local items. At worked we use git and I like it better than other alternatives (except RCS).

My only complaint I have for git is it does not support $Id$ and other RCS variables. IIRC that was by design.

Re: Oh Shit, Git

#85
post #4

Git is a reminder why even the best minds in software development sometimes really should talk to UX/UI people.

To me, Git is designed in a very nice and understandable way with a terrible terminology. I might be an exception though.

Re: Oh Shit, Git

#86
post #51

Earlier quoted context omitted.

Git was built with a very specific use case and aimed at an extraordinarily technical subset of users. It dominated the world despite the UX flaws, which suggests they really aren't that bad.

They are bad. Some concepts like rebase etc. I still don't understand. In software we often go for further complexity instead of less. I think because most of us who are the lead developers are often the most intelligent. And we often enjoy these complicated abstract models and they come easy to us. However in satisfying our own intellectual vanity we often don't see how many we leave behind. Which is good for our ho…

I'm sorry if this sounds arrogant, but if you don't understand basic Git concepts like rebase, I don't think you're in a position to comment on the architecture of Git

Re: Oh Shit, Git

#87
post #74
post #33

Earlier quoted context omitted.

I'd argue the opposite - that the model was so good and so much better than anything else that it was adopted despite the UI/UX flaws. Things can be good, have a flaw and still be considered good. That doesn't mean that we pretend the flaw doesn't exist.

Mercurial is built on what is almost the same model and has what I think is a better UI/UX. Some people say that git is technically superior but you really need to be an advanced user for it to matter, or work on a really large project. At work, we switched from SVN to Mercurial, and from Mercurial to Git. Most people were happy to switch away from SVN, but few enjoyed the change from Mercurial to Git. Personally, it…

> Why Git came to dominate and not Mercurial?

I was an early proponent of Mercurial over git. While they are similar, a few “minor” things made a big difference:

Mercurial distinguished between branches and heads, whereas git did not. This added extra complexity.

Git embraced checksums as identifiers while Mercurial provided local revision numbers, this obscured the mental model.

Git is faster to pronounce than either “Mercurial” (which has a tricky vowel in there) or “hg”.

Re: Oh Shit, Git

#88
post #4

Git is a reminder why even the best minds in software development sometimes really should talk to UX/UI people.

Is it, though? I'm not so sure. Git has enjoyed overwhelming success, which would seem to empirically indicate that it's done something right in terms of design Perhaps the obviously wrong UX/UI isn't wrong? Perhaps UX/UI people aren't good at designing interfaces for experts?

Git has been successful despite the UI, not because of it.

Re: Oh Shit, Git

#89
post #70

Earlier quoted context omitted.

> for knowingly setting up ill-conceived software to go viral I doubt that was the intention. Linux just needed a versioning system tailored to its needs, and that's exactly what Git is. Can't blame its creators that other people used it for scenarios it wasn't built for.

Right, you are the cop-out I am complaining about. Linus is the premier figurehead of the premier open-source project. When a build tool he made for that project goes viral it isn't an accident. If it was anybody else's pet versioning control system would we even be talking about it?

If it went viral, yes. I agree most of the time I feel like the world is run by evil folks twiddling their fingers in secret.

This is not one of those times. I agree there's a chance there are better word choices or feedback for some commands, but overall once you 'learn the language' it really is a lean, mean, well designed piece of software.

Folks that complain about the UI/UX don't realize it wasn't designed for less technical folks. It was designed for the folks who needed it.

It's success must at least partially prove that the UI/UX is not 1/10. Any real engineer will tell you, there are times where they wish they could do something better but the requirements and constraints left them making tough decisions, and that doesn't mean they aren't proud of their work.

It's success is also partially due to the fact that it is lean and mean, which allows it to be applicable to nearly all software projects of any flavor. So I don't understand why folks argue it could have been done better. If it was 'better', in my view it wouldn't have been successful. The success was driven by it's succinct design and Linus' take it or leave it attitude.

Technically accurate studio monitors don't sound as pleasing to the ear as good well tuned speakers. But they are exceptional at the job they were designed for. This is like that.

Re: Oh Shit, Git

#90
post #88

Earlier quoted context omitted.

Is it, though? I'm not so sure. Git has enjoyed overwhelming success, which would seem to empirically indicate that it's done something right in terms of design Perhaps the obviously wrong UX/UI isn't wrong? Perhaps UX/UI people aren't good at designing interfaces for experts?

Git has been successful despite the UI, not because of it.

Can you substantiate your opinion?

It's open source, so why hasn't an alternate interface taken over?

Post reply on HN