Hacker News Reader

Comment by bsder | Hacker News Reader

> Git is not a natural development at all. Obviously, it is a standard right now.

Git is actually an unnatural development. Its UI is atrocious. And it worked like crap on Windows for forever.

Over time, I taught non-computer people who used Windows all of CVS, Subversion, and Mercurial. They got each one and why things were better. The first time they had to recover something, they really got it. Source control got out of their way and was generally fine.

Then Github won due to VC cash dumping and foisted Git on all of us. Source control was no longer fine.

Thankfully, there is now Jujutsu(jj) which works on top of the Git storage layer so you can forget about the craptastic UI of Git. Source control is now fine again.

View on HN

GitHub won because it was good.

SourceForge had a messy interface and frankly I hated it. Google Code was like frozen in time, like most Google projects. Microsoft’s thing — I don’t even remember the name — felt half assed and like they were going to abandon it… and they abandoned it. There were also others… none of which I even think were serious enough.

Also Git won because SVN and CVS were centralized VCSes and you needed a server. I can just make Git repos before I even know if a project is serious.

There were other distributed VCSes of course, like Hg, but they either cost $ or wasn’t backed by a major user… like Linux. I admittedly just waited this one out and chose Git because it was more popular.

You either meant Visual SourceSafe or Team Foundation Server for the Microsoft product.

SourceSafe did get abandoned... because your source wasn't actually safe in it.

Its replacement, Team Foundation Server got rebranded as Azure DevOps; but the product's still around, 19 years later.

Yes, but it's source control shifted to git years ago (I think you can still use TFS, but it's strongly legacy ) and git is mich better than TFS ever was.

True on both counts. (They’re never going to be able to kill TFVC entirely, but it’s disabled for new projects by default, and they’re going to take away the switch to reenable it.)

GitHub won because it was free.

If git doesn't need a server, then why do you need Github?

This discussion was about git, not GitHub. There's a difference.

GitHub won because they built a great product. It was better than all the alternatives and people flocked to it for that reason.

Git itself is mediocre, and some other DVCS like Mercurial could have won out, although HgHub really doesn't have the same ring to it. The halo effect from the Linux kernel was also a factor. But the VC cash dump and Microsoft buyout came later, people used GitHub because it was better than the rest.

Mercurial lost because it had the wrong mindshare. It was the Betamax of version control and while it had a lot of positives, it never gained the critical mass to overcome VHS.

Which is such a tragedy. Hg is such a simple pleasure to work with.

It's sad that this discussion about git being the standard turned into "Why GitHub won" -- shows that people conflate the two. Who said GitHub had anything to do with git becoming the standard in the first place? (I only even heard of GitHub long after we'd adopted git at a previous workplace.)

git didn't win because of GitHub. Sure, GitHub helped a lot. But actually, it's because its a DVCS, and it does branching and merging way better than anything I've seen so far.

You can thank BitKeeper for all of this, and Andrew Tridgwell for forcing Linus Torvalds into creating git.

You don’t think if the company behind GitHub went all-in on mercurial that might have emerged as the winner? There were plenty of companies using either. Git wasn’t the only distributed game in town. I definitely think GitHub had a lot to do with it.

Before there was GitHub there was Sourceforge. Sourceforge supported several different protocols and git still won.

Gits internals can be confusing at first, but once you understand them there's really nothing you can't do. Being distributed by design also helps.

yeah, git is just the right layer of indirection to support everyone's weird take on how the workflow should go, so you can just use it however you want.

Sourceforge had a flat namespace for projects and required you to manually apply for each project. It was a PITA and that added a huge barrier to entry.

Plus it didn’t have a mechanism to send contributions. I think GitHub “won” because of its web-based PR system.

Sourceforge isn't GitHub. What's the relevance?

If you think SF+CVS is equivalent to GitHub+Git then you never used SF+CVS. Git won because of GitHub, specifically, not because generically it could be hosted on the Internet.

No, GitHub won because of git, lots of VC (later MS) money, and brilliant marketing that makes people think "Git won because of GitHub".

Sourceforge was complete garbage though. I hated, hated when projects were hosted on it. It was slow, full of ads, impossible to find what you need to download..

GitHub is to sourceforge what Facebook was to MySpace. MySpace was first but it was buggy as hell.

That comparison is pretty harsh and really underemphasizes how awful sourceforge was. Myspace was mostly fine, death by feature creep. Sourceforge was a flaming pile of garbage that was poorly designed, ad laden, AND silently bundled in ad/spyware to normal downloads.

A more apt comparison would be comparing Facebook to a hypothetical social media site that when you click on a thumbnail of a user's image, you get a fullsize image of something like goatse...which thankfully doesn't exist(yet).

You mean the comparison is too mild? https://www.merriam-webster.com/dictionary/harsh

Oh, meant harsh to Myspace, which wasn't that bad really.

I read it as harsh to MySpace, because that was very unfair to MySpace imo

SF started to be filled with ads only in a second phase. By memory I would say around 2010, and checking Wikipedia it says it changes ownership in 2012. But when it was the de facto "central repository" for Linux softwares codebases, I don't remember it being full of ads.

You're kind of disproving the point you're trying to make, IMO: Saying "GitHub made git the standard!" is kind of like saying "Facebook invented social media!"

Nope, MySpace did. Or blogs, for that matter. Facebook just co-opted the phenomenon, and has for many become synonymous with it. Just like GitHub has managed to do with git.

Sourceforge wasn't the only offering at the time.

Lots of companies were doing Git and Mercurial "forges" at the time. Many of them were better than Github.

Everything was evolving nicely (including Git and Github) until Github used VC money to offer everything for free to blow everybody out in order to lock people into their product (for example--export of anything other than code is still hit or miss on Github).

At which point, everything in the source control space completely collapsed.

That's such a weird rewriting of history. I know blaming VC is very fun and all, but Bitbucket, originally centered around mercurial, had just as much resources as GitHub and even more. Tons of early contributors to git and the ecosystem were from google and Microsoft. Microsoft started using and shifting towards gif when GitHub was still a baby, etc.

> That's such a weird rewriting of history. I know blaming VC is very fun and all, but Bitbucket, originally centered around mercurial, had just as much resources as GitHub and even more.

You might want to go review your history before accusing someone else of that.

Github took $100 million from VCs in 2012. It then took another $250 million from VCs in 2015. Who the hell else was even within an order of magnitude of that in the same timeframe? Nobody. (Gitlab took almost the same amounts but did so somewhere between 5-8 years later depending upon how you count).

Bitbucket got bought by Atlassian in 2012. Atlassian was bootstrapped until it took $60 million in VC in 2010 and had revenues (not profits) of about $100 million in that time frame. It had nowhere near the resources to be able to drop the equivalent of $350 million on Bitbucket between 2012-2015.

By 2012 the writing was already on the wall. This was already well into the first PaaS era with Heroku, Engine Yard, etc. Github was bootstrapped, and using git was a grassroots movement. It was just better than what most people had been using. I never looked back after first switching from SVN to git in 2009.

VCs didn't make git successful, developers did.

Sure, but 2010 to 2012 might as well be two different eras in the context of VCS adoption. Things changed very quickly.

In any case,that doesn't really matter considering that git had big players adopting before GitHub got any sizeable investment. And I'm not just talking about Linux. Rails migrated towards it when GitHub was still in beta.

Minor nit.

> Bitbucket got bought by Atlassian in 2012.

29th September 2010[0] (just over a month after Atlassian raised the $60M.) ~18 months before Github took any VC money. If the VC money was key to Github's success, why did Atlassian/Bitbucket's 18 month head start not get them anywhere?

[0] https://web.archive.org/web/20160303204710/http://www.itwire...

To be fair, by the time git came around, sourceforge had been enshitifying itself for 10 years or so. Git would be popular without github, github just makes things easier.

> Git would be popular without github,

Yep.

> github just makes things easier.

Which is the transition between steps 1 and 2 of Embrace, Extend, Extinguish. Though the last step is nowadays perhaps unnecessary, depending on how you look at it: Having co-opted FOSS software like git, what you need to extinguish is not that itself, just any other way to use it than your own. The main example of step 2 was of course "Pull Requests".

> I definitely think GitHub had a lot to do with it.

And I definitely think you're wrong. GitHub has managed to get itself conflated with git, and has benefitting hugely from this confusion.

Yes, git has solved a big problem with version control: it has made transactional atomic changesets (commits in the git parlance) mainstream. A git repository is a tree of atomic changesets that group changes into meaningful chunks as opposed to a versioned tree of files where changes to each file are harder to trace back to the intent, i.e. whether or not they are related.

Atomic commits can also easily be moved around (since the repository is a tree of commits with the commits being leaves), and they also make merging simpler in many scenarios.

Larry McVoy was famously wont to engage in trolling upon the Linux Kernel Mailing List, whereupon he did boast of his BitKeeper, which possessed atomic changesets. Concurrently, he did deride Subversion for its lack of the same. Thus, a great drama did ensue, one which ultimately bestowed upon us the creation of git.

git has also succeeded as a DVCS where others have faltered, for various reasons. For there have been monotone, darcs and other such systems; yet, it is chiefly git that has endured.

> it has made transactional atomic changesets (commits in the git parlance) mainstream

Nope. Subversion made them mainstream:

"An svn commit operation publishes changes to any number of files and directories as a single atomic transaction. In your working copy, you can change files' contents; create, delete, rename, and copy files and directories; and then commit a complete set of changes as an atomic transaction.

By atomic transaction, we mean simply this: either all of the changes happen in the repository, or none of them happens. Subversion tries to retain this atomicity in the face of program crashes, system crashes, network problems, and other users' actions." [0]

[0] https://svnbook.red-bean.com/en/1.5/svn.basic.in-action.html

> Larry McVoy was famously wont to engage in trolling upon the Linux Kernel Mailing List, whereupon he did boast of his BitKeeper, which possessed atomic changesets. Concurrently, he did deride Subversion for its lack of the same

Subversion definitely has atomic commits. That was it's major advance over CVS.

The major difference between svn and git/hg is svn assumes a centralised repository, whereas git/hg are designed to work as distributed repositories that exchange change sets.

Turns out that you can build sophisticated work flows on top of features they added to support that distributed model - things like PR's. These things are useful even if you have a single centralised monorepositiry of the style svn insists on.

But atomic commits aren't part distributed feature set. You need them in a monorepositiry. After you've experienced your CVS repository being turned into a mess by two people doing a commit at the same time that becomes obvious.

git isn't foisted on anyone, although I will acknowledge that if you're working anywhere remotely web-y, you'll be required to use it.

But the vast majority of people I personally see who complain about git simply don't know how to use it, and apparently don't care to learn. They say it's hard, and then they joke about never learning more than three git commands. Can't we do better? Is that where the bar is?

It's not that the basics of git are hard. It's that there are 30 footguns you're forced to deal with every time you want to do anything, just because someone somewhere once had to use one of them -- probably caused by another one of them.

Git lovers mostly use it as a file copy service.

> Git[‘s] UI is atrocious.

Well, that’s in the eye of the beholder. Yes, I hate the ‘program command’ syntax (“git add”, “git commit” etc) but I just call git-add etc and for me those commands are pretty clear.

But I understand how git works. I imagine most people treat it as a black box and then its behavior probably is rather obscure. I don’t think it was intended for that use case.

> Well, that’s in the eye of the beholder.

I acknowledge that Git is really good on a technical level, but don't like the CLI experience regardless.

Instead, I much prefer to use tools like GitKraken (paid), SourceTree (free, limited platform support), Git Cola (free, lightweight, a bit basic) and know that most of my colleagues just use the Git integration in their IDE of choice.

Working that way, it's a decidedly pleasant experience, not unlike using visual merge tools like Meld, where you can also stage individual lines/code blocks and operate with branches and tags in a very visual and obvious manner.

That said, sometimes the support for Git LFS and things like submodules is all over the place and I've had cases where not adding node_modules or something like that to .gitignore has made the UI unresponsive with how much stuff initially shows up in the working copy, so sometimes you still have to drop down to the CLI and do a fix herer and there.

git has plenty I like and lots of things I would rather not do, but I find most GUIs too obfuscating. I do patch adds, I prefer resolving conflicts in the raw file, and as many plugins as I’ve tried for vim to make git “pretty”, they just don’t hit for me. I used Kraken for a while but ultimately it just felt like unnecessary fluff - knowing the commands I’m using makes me feel like I know what’s going to happen, and GUIs make me feel like I’m not sure. I’m happy for my coworkers that use them, and I’m also usually the first person to get a ping when something beyond what makes sense in the GUI comes up.

>> Git[‘s] UI is atrocious. […] Over time, I taught non-computer people who used Windows all of CVS, Subversion, and Mercurial.

> Well, that’s in the eye of the beholder. […]

I would say it is not.

Usability testing is a thing, and products can get better and worse scores when trying to do the same task / reach the same result. I'm not aware of any published studies on the topic, but I would not be surprised if Git got lower scores than Hg on UI/UX, even though they can basically do the same thing (distributed development).

Given the GP trained people on multiple version control systems, including another distributed one (hg), and people mostly had a problem with Git, I would say Git is the problem.

I am unable to do anything with Photoshop beyond starting it and exiting. I have no idea how or even what it does beyond somehow modifying photos. That’s not photoshop’s problem, it’s that I don’t know what I’m doing. So I just don’t use it.

I only hear git complaints from people who don’t have an internal model that reflects what git is doing (I’ll agree that it uses a couple — but only a couple — of terms in a way that might violate some people’s intuitive model). But if you know what you want to accomplish the command line is pretty unremarkable.

But when you don’t know how the tool works you easily get snarled. And when you blindly resort to various “cheat sheet” sites it’s a crap shoot whether you “fix” your problem (how would you know?) or make things worse. That’s like me with photoshop.

I used to see this with CVS too

> I am unable to do anything with Photoshop beyond starting it and exiting. I have no idea how or even what it does beyond somehow modifying photos. That’s not photoshop’s problem, it’s that I don’t know what I’m doing. So I just don’t use it.

As stated up-thread:

> Over time, I taught non-computer people who used Windows all of CVS, Subversion, and Mercurial. They got each one and why things were better. The first time they had to recover something, they really got it. Source control got out of their way and was generally fine.

Seems that things only got hard(er) teaching people with Git.

> I only hear git complaints from people who don’t have an internal model that reflects what git is doing

Yeah, every time someone says that:

> git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space.

* Isaac Wolkerstorfer, https://twitter.com/agnoster/status/44636629423497217

In the past I have used RCS, CVS, and Subversion. I never had to learn any kind of internal model for any of them.

I'm consistently baffled by the people who don't understand how git works who then complain that it's hard. Yes, of course something you don't know is hard. Version control is a hard problem; I'm not sure why so many expect it to be unicorns and rainbows.

Reply on news.ycombinator.com