Hacker News Reader

Comment by nananana9 | Hacker News Reader

Git is industry standard, because for what it give you it's a remarkably robust and simple program to use. We're all vaguely aware that the internals are complex, but the UX is clean and usable enough that the complexity usually doesn't leak out.

But the day this breaks down and I have to deal with bloom filters, packfiles, maintaining the git garbage collector or rerere cleanup, is the day I switch our codebase to a centralized VCS.

This stuff is cool to learn about; but it's 5 layers removed from anything I want to be thinking about in my day to day work.

View on HN

I'm pretty sure git is industry standard almost entirely entirely because GitHub exists. And I very much disagree that the UX is clean. The cli is more than a bit of a mess.

Anyone who has ever used Mercurial knows very well what a good versioning tool UX looks like...

> Anyone who has ever used Mercurial knows very well what a good versioning tool UX looks like...

So true. I used Mercurial back in the day and also used Darcs before it, and it helped me realize that the best versioning tool UX that exists is still the one Git provides.

PS: Also CVS, SVN, Perforce, and Clear Case professionally, and gave a try to Fossil. None of them even close to Git usability-wise.

No. When I left a job using Mercurial, I made a vow never to start a job that used it again. And that employer was seeking to move on from it.

good because clones take forever so you get free time? Good because you need plugins/extension/special-config to support rebase?

> I'm pretty sure git is industry standard almost entirely entirely because GitHub exists.

Nah, I remember that time vividly, Github became a thing about a year or two after it was already very much taking the lead.

GitHub became GitHub because git was the winner. There were alternative hubs that supported bazaar and mercurial and whatnot, but git won because for most people, Linus and the kernel team being behind it was reason enough to trust it.

(and I say this as someone who liked hg more than git)

I mean, I don't think anyone can say for sure if "GitHub became GitHub because git was the winner" or "Git became mainstream because GitHub won the developer mindshare", pretty much everyone I knew used GitHub for everything besides the actual VCS protocol, although a lot of us early users were users of GitHub especially because of git.

Most people just wanted to collaborate on the platform other people were on, and where the popular projects were, that it used git was just an implementation detail at that point for most I think.

Git was blazingly fast when it came out, faster than hg (C vs Python) and of course a different order of complexity to svn, which was the actual existing alternative it supplanted.

i think it is the other way around. Git is pretty simple internally, and its ui is just knobs and levers to reach into that simple reliable internal structure. This is why for some people it seems like a mess - they want button "do what I want" (and all people and their needs are different), and for other people it's clean - open the throttle, engine will rev.

Agree, the insides are fairly simple and cleanly designed, you could explain exactly how almost everything works in a 1 hour presentation, and most people will grok the main ideas fairly easily.

The tooling on top is inconsistent and kind of messy though, and harder to explain than the internals. I recall hearing somewhere that the tooling we see today as the user tooling was really supposed to just be the tooling for messing with git directly, with the expectation that something would sit above and make it actually user-friendly. I don't remember where I recall this from though, so could be just a post-justification from my own brain to explain the situation :)

It’s more about using them to present a better interface for your workflow and the project.

> Git is pretty simple internally, and its ui is just knobs and levers to reach into that simple reliable internal structure.

that's not true either. originally it was simple internally - it was mostly shell scripts! writing text files! - but now it has all sorts of complicated optimisations.

the "middle" is somewhat simple for CS people, though - a graph of commits, you can put labels on them, you can send and receive strict appends to the graph to another repository. both the stuff under and above that is quite complicated in practice, but the UI does continue to improve - e.g. editing a past commit message until the release last week was ... complicated.

> editing a past commit message until the release last week was ... complicated

Was it? ‘git log —-oneline’ to figure the commit id if it’s not really recent. ‘git rebase -i <commit-id>^’ and then apply the reword action to your commit.

Reply on news.ycombinator.com