Why GitHub won

> code.google going away, without the excuse that google itself was going away, after I had started to rely on it and link to it in docs and scripts all over the place

It didn't go away, though. It got archived and that archive is still up and running today. Those links you put all over the place should still be working.

> If google had said "The purpose of this service is an academic goal of Googles, not to serve users needs. This service will be shut off as soon as Googles academic purpose is met." I would not have used it.

That's not an accurate representation of what DannyBee said. Moreover, what DannyBee did say is in line with what Google itself said was its goal when the service launched: https://support.google.com/code/answer/56511

"One of our goals is to encourage healthy, productive open source communities. Developers can always benefit from more choices in project hosting."

> Effectively, Google harnessed users for it's own purposes without their consent by means of deception.

This does not appear to be a good faith argument.

None of what DannyBee said in their comment aligns with that interpretation. Neither does that interpretation line up with Google's publicly stated goals when they launched Google Code.

This is a repeatable pattern:

  1. A well-known major company sees that people are relying on something broken and it's hindering progress.
  2. The company decides to compete with that thing, but it's not part of their mission, so they make it free.
  3. Because the new thing is free, and run by a major company, lots of people come to depend on it, even though it's intentionally not the best.
  4. Another company builds more competition and works to actually be the best.
  5. The major company sees that their original objective of replacing the bad version is fulfilled, so they sunset the thing.
  6. People who came to depend on the thing feel betrayed.

This is why we should all be cautious about any non-core free service from major companies.

I hate to break it to you be GitHub is going to shut down too. Everything does.

> Google harnessed users for it's own purposes without their consent by means of deception

Every profitable company on earth, ever.

Every project by Google I was willing to jump platforms for, they killed. So outside of email, maps, and search, sometimes voice, they have nothing left that is worth investing time into. It will disappear within a couple years or less.

> fun side projects that a multibillion dollar corporation is doing out of the goodness of their hearts

Back then it felt like it was actually just possible that they just were that cool. Noughties Google was really something compared to the staid, implacable incumbents. 15GB (with a G!) of email storage that would grow forever! Google Earth! YouTube! Live long enough to see yourself become the villain indeed.

As for real products, at Google's current size it has become near impossible to launch new ones worth their time.

Google currently has a quarterly revenue of $70-80B.

Imagine an internal team launches a new product to collect $100M in quarterly revenue. An earth-shattering success for any entrepreneur.

For Google...it doesn't even move the needle. Does nothing for stock, it's not strategic, and may become a liability later on.

You would need to launch a multi-billion new sub business for it to be of any interest to Google, which is impossibly hard.

That's the big question mark I have for Flutter. Looks like a pretty nice platform from the outside, but I cannot see Google NOT killing it

Google Maps isn't going anywhere. I'd even argue that it's more important than search; it's far more difficult to switch to a competitor.

GMail isn't going anywhere either.

YouTube is a bit less clear: it doesn't really have any competitors, and is extremely popular and widespread, but it surely costs a fortune to keep running.

It'd be interesting to see the financials on these different business units to see which are the healthiest and which aren't.

Business strategy is more than just launch product, make money. Companies operate in a dynamic space, and if you play any game (basketball, chess ..) you know that moving forward at all cost is not how you play the game. Sometimes you side-step, sometimes you take a step back, sometimes you sacrifice your piece.

If you expect you team to just go-go-go, you might something in the short term but you'll fail miserably in long-term.

I don't even use search anymore. Kagi schools it

Eh, when it happened the world was ready. It felt like a different internet back then, and it was pretty great for a company to say that everyone was already on github anyways, so let's all go there (Microsoft followed almost the exact same timeline with Codeplex, and really who cares).

More Google style would be shortly after shutting down Google Code starting up a new code hosting project, migrating several times to always slightly incompatible frontends requiring developer changes, shutting down the project, and shortly afterwards starting up a new code hosting project...

Unrelated to the thread - do you use any email providers with a custom domain? If so, would you suggest them? Who are they?

mentioning the sunset of a google products, in general, in any thread about some specific google product, is a kind of godwin's law.

because of ordering by vote, we can't see how quickly it happened in this case. in godwin's law the likelihood increases by length of discussion, implying a slow/linear kind of probability, but for google product sunset i would argue that the likelihood ramps up very aggressively from the start.

i hereby dub this `jiveturkey's law`.

like godwin's law, the subthread becomes a distraction. unlike godwin's law, the sunset distraction is always a legitimate point. it's just that it has become tired.

a simple heuristic: does it make Google a boatload of money? if yes, it's safe

I'm still dealing with the fallout of the domains selloff.

"I'm not a journalist, but in an ideal scenario, how would somebody have known that you were one of the key members of the project?"

It's not about asking me, it's about not asserting things you don't know.

Instead of saying "people did x for y reason" when you have literally no data on x or y, you could say "I don't know why x happened, i only know about z". Or if it's super important you try to put something there, beforehand, you could say "hey does anyone know why x happened? I'm working on a blog post and want to get it right".

Then, someone like me who saw it could happily email you or whatever and say "hey, here's the real story on x".

Or not, in which case you can leave it at "i don't know".

The right answer is not to just assert random things you make up in your head and force people to correct you. I'm aware of the old adage of basically "just put wrong stuff out there and someone will correct you", but i generally think that's super poor form when it's about *other people or things and their motivations". I care less when it's about "why is the sky blue".

In this case, it also happens that there are plenty of on-record interviews and other things where what i said, was said back in the day.

So a little spleunking would have told them the answer anyway.

The way it used to work is that tech journalists (or sports journalists, or any other type) had contacts in the industry. If those people were not directly involved, they probably could at least suggest someone else who might know. Leads were followed up, and eventually the writer got the story.

I'm not sure how it works now, cynically I would suggest that the writer asks an LLM to write the story, gets a rehash of Wikipedia and other sources, and they maybe makes some attempts at firsthand verification.

Well, finding, vetting, and getting comments from sources is like half of journalism. If you can't or won't do that, whatever you are doing is probably not journalism. It's just an editorial, think-piece, or whatever.

Journalists are supposed to investigate not speculate because finding an email is too hard

Maybe a cofounder of GitHub has the reach and network to ask for the e-mail of someone who worked on the Google Code team. A journalist might not, that's true.

Just flat out saying they had no taste in product development, however, is a bit of trash talking for no reason.

"If Google Code succeeded, it’s hard to imagine that Google would not have tried to monetize it someday."

Google code did succeed in that sense. It had hundreds of thousands of 30-day active projects, and some insane market share of developers.

I don't honestly remember if it was even shrinking when we decided to stop taking in new projects.

I doubt we would have monetized it directly (IE sell an enterprise version) - the entire market for development tools is fairly small.

In 2022 it was ~5 billion dollars, and future estimates keep getting revised downwards :).

CAGR has been about 10-14% in practice, sometimes less.

I don't remember if it's still true, but most of that 5 billion dollars was going to Atlassian (80% at one point).

Now, if you project backwards to 2006, and compare it to other markets google could be competing in, you can imagine even if you got 100% of this segment it would not have actually made you a ton directly.

Indirectly, eh, my guess is you still make more off the goodwill than most other things.

It's actually fairly rare to make any significant money at development tools directly.

Nowadays, the main source even seems to be trying to sell AI and productivity, rather than tools.

It seems highly likely that a successful Google Code would be used as an onramp to Google Cloud. IOW, indirect monetization so it likely would still have a generous free component.

Relatedly, it is hard to understand how operating Google Code in a manner “never trying to win”, “not trying to make money, or whatever” and “just to prevent … a monoculture” was in the best interests of Google the corporation and its shareholders

It’s short for Source Forge which is still around technically but a shadow of its former self.

The fact that letters "SF" may need explanation in a context of code hosting and building says how thoroughly the job has been done. A number of good alternatives exist, there's no monoculture (even though some market domination is definitely in place, but now by a mysterious GH).

SF is SourceForge, which at the time effectively had a monopoly (and also sucked)

I now realize that it's SourceForge. :)

Sourceforge.

This post replied to a post talking about Source Forge. Had the same problem :)

I think it means SourceForge.

SourceForge, probably.

SourceForge

Developer infrastructure at google reported into cloud from 2013 to 2019, and we (i was there) tried to do exactly that: building products for gcp customers based on our experience with building interval developer tools. It was largely a disaster. The one product I was involved with (git hosting and code review) had to build an MVP product to attract entry level GCP customers, but also keep our service running for large existing internal customers, who were servicing billion+ users and continuously growing their load. When Thomas Kurian took over GCP, he put all the dev products on ice and moved the internal tooling group out of cloud.

New GitHub full text search [1] is amazing. It is so good that for me it often replaces StackOverflow - I just use it to see how some API function is being used. Especially useful if you're searching for an example with a specific argument value.

[1] https://cs.github.com/

Do you mean the non-semantic indexing, which covered most of Google Code? Like grep-style supporting, but no real semantic data?

Or are you talking about the few repos that had semantic indexing via Kythe (chromium, android, etc)? We never got that working for generic random open repos, primarily because it requires so much integration with the build system. A series of three or four separate people on Kythe tried various experimentation for cheaply-enough hooking Kythe into arbitrary open repos, but we all failed.

Being a Google insider comes with the gift of being able to see the real rationales behind many products, and also the curse that nobody outside will believe you.

This is perhaps true of all big companies, but Google also seem to adopt a more passive PR strategy and don't try too hard to explain things, and it's just that much more difficult to understand Google when everyone else is louder.

different projects have different objectives? The guy literally worked on the project! There were 4 people at its peak! Why would you think that would be the source of a major initiative?

Though there probably is some deeper critique about how you have a pretty amazing service running with "just" 4 people and aren't able to turn that into something useful beyond that objective. Innovator's Dilemma I guess.

>Google Video was created to prevent Youtube from becoming a shitty monoculture, too?

Like Google+ and all the other attempts:

https://killedbygoogle.com/

Google is actually the good guy to prevent monopolies, we just don't understand them ;)

Well, it is hard/very distasteful to put ads on a source code hosting website, so this likely isn't aligned with Google's interest. No, I am not joking.

This was 2006 Google, which did stuff semi-altruistically all the time.

At that point, SF was serving malware and stuff. It was really not a great time.

Github became a monoculture years later when others folded. Google code was shut down in 2016. Github wasn't quite a monoculture then.

I also said, back in 2014, that it might be necessary to do something like google code again in 5-10 years: https://news.ycombinator.com/item?id=8605689

10 years later, here we are i guess :)

Though i think what i said then still holds - Github is not anywhere near as bad or unreliable as SF was.

For a comparison on the scale of harm from the monoculture, recall that SourceForge was bundling malware with downloads, and still has a full page of ads when you download from it.

If I recall correctly, SVN was also more popular than Git at the time, so migrating hosts was a lot more painful than now...

> It's a bit of a cop out to say "we were never trying to win"

It's literally not? We had a goal from the beginning - create enough competition to either force SF to become better (at that time it was infinite ads and malware), or that someone else wins.

> You should have been trying to win, you should have built a strong competitor to GitHub and you shouldn't have let it rot until it was shut down

That's your goal, not mine (or at the time, Google). Feel free to do it!

You don't like what we had as a goal - that's okay. It doesn't mean we either failed, or had the wrong goal. We just had one you don't happen to like.

> The world would have been a better place if Google code tried to be as good as GitHub

One of the things to ask before you either start something or keep doing something is "who actually wants you to win?" If the answer is "nobody", it might not make any sense to do.

It's not obvious in 2016 anyone would have wanted us to win. By then, Google had lived long enough to see itself become a villain. There was reasonable competition in the space.

I don't believe we would have really served people well to keep going.

It was similar with Chrome. Internet Explorer was the monoculture browser and stagnating. Google had things they wanted to do on the web but needed better browsers. The original goal was to introduce competition in the browser space so that all browsers would get better. They may have changed goals along the way, but that was the original stated goal. In the end they killed IE and now they are the monoculture outside of Safari.

Different groups of people have different goals. Not every group of people has "winning" a market as their primary goal.

> If you were never trying to win, that's a product failure.

what?

2013 is when the binaries had malware included although even in 2008 they were guilty of having 5 download buttons due to excessive and unpoliced inline advertising with only one of those buttons being the holy grail that linked to the download you actually wanted. Choose wisely.

To help our recollections, let's look at Sourceforge's browse page, from back in 2008: https://web.archive.org/web/20081118033645/http://sourceforg...

They did indeed host quite a lot of stuff, and it was undeniably popular as a place to get your binaries hosted free of charge.

But at the same time, is it being used as a source code repository? A lot of those projects don't show the CVS/SVN features. And sourceforge never hosted the biggest and most established projects, Linux and Gnu and PHP and Java and Qt and Perl and Python were all doing their own thing. And pretty much every project visible on that page had its own separate website, very few projects hosted on sourceforge exclusively.

Who is "we"?

>I would also argue that MS is nothing like the company that it was 30 years ago when that philosophy was a thing.

This is like saying that a cannibal has stopped eating people because there have been no disappearances in the last two days. Sure, technically correct, I'd still not eat their curry.

MS have realized that producing the right kind of important open-source software gives even more strength than producing closed-source software. Hence Typescript, VS Code, a few widespread language servers, etc.

> The truth today is the via GitHub, Microsoft hosts the vast majority of the world's open source software, entirely for free.

To be fair, though, y'all did 90% of the work before the acquisition. MS only hosts the vast majority of the world's open source because they backed up dump trucks full of cash at the houses of the people who actually built that capability.

> I would also argue that MS is nothing like the company that it was 30 years ago when that philosophy was a thing.

I don't think I can ever truly trust their motives, though. I will agree that it's a different company in many ways, but their history is still that of a company that, through anti-competitive practices, set personal computing back decades. And worked tirelessly to keep open source at bay where they could.

At this point MS realizes it's more profitable to work along side open source than against it. If at any point they no longer believe that's the case, you better believe we'll see a reversion to their former behavior.

The truth is that Microsoft trains Copilot using the vast majority of everyone's code, entirely for free.

Corporations like Microsoft don't do charity.

There was concern actually. We debated a bit the concept of naming the company "GitHub", since "git" is baked into the company name. We worried a little about what happens when the next big VCS thing comes along, not knowing that it's going to be dominant for at least the next 20 years.

I didn't say it was. If anything, it's preferable to "extinguish". :)

Though a core philosophy behind the OSS movement is creating software for the benefit of humanity, instead of driven by financial reasons. Not that developers shouldn't profit from their work, but it's ironic that a large corporation who was historically strongly opposed to the movement is now a leader in it. It's understandable to question their motives if you remember the history, regardless of their image today.

Pull requests predate Git. The kernel developers used them in the Bitkeeper days:

    I exported this a patch and then imported onto a clone of Marcelo's
    tree, so it appears as a single cset where the changes that got un-done
    never happened.  I've done some sanity tests on it, and will test it
    some more tomorrow.  Take a look at it and let me know if I missed
    anything.  When Andy is happy with it I'll leave it to him to re-issue a
    pull request from Marcelo.

https://lore.kernel.org/linux-acpi/BF1FE1855350A0479097B3A0D...

I do not know to what extent Bitkeeper had browser-based workflows. Moving cross-repository merges away from the command line may actually have been innovative, but of course of little interest to kernel developers.

I remember we used a tool, I think it was Gerrit, before I'd heard of GitHub or Pull Requests. It worked with patches which is also how we used to share code, through email with patches. GitHub won because it had a cleaner UI and a likable name.

I taught my research group Git version control in college. It was part of a "new student/researcher onboarding" series that we put all the new grad students and undergrads through. But we were in Radio Astronomy, so there was a lot of data processing and modeling stuff that required being comfortable within a remote ssh session and the basics of Linux/bash/python. I know it was already being used in Radio Astronomy (at least in the sub-field of Pulsar Astronomy) at the time and was part of the reason I didn't get pushback when I proposed making sure our group was trained up on using it.

We switched to Git as a whole in early 2009 since it was already a better experience than SVN at the time. Could be off by a year or two, given how long ago this was and the fact that I was working with the group through the end of high school in 2007-2008.

We only added GitHub to our training later in 2011-2013 era, but we ran our own bare git repos on our department servers until then. And students/groups were responsible for setting up their own repos for their research projects (with assistance/guidance to ensure security on the server).

Last job also made use of our own internal bare repos, admittedly mirrors of our private GH projects, and our stack pulled from that mirror to ensure we always had an instance that was not dependent on an external vendor.

Current role also makes use of bare git repos for similar reasons.

I think the knowledge is there and plenty people do it, it's just not news/blog worthy anymore. It's not new or groundbreaking so it gets little attention.

Me, I picked Python and Mercurial for primary language and DVCS, respectively: one of those worked out really well. I still miss hg and have never really gotten the hang of git.

Regarding Mercurial, would you happen to have recommendations for a GitHub/Bitbucket-like service that still works with hg?

As someone who used both git and hg, I must say I'm sorry git won. Its chrome sucks (though less than it did) and the naming is confusing as hell. Still, if everyone uses git, and you have to use BitBucket for hosting instead of GitHub/Lab... Nah, not worth it. Kudos to you for sticking with it!

Git is still a DVCS, even today it's not being used in the way it was designed to be used by Linus and co.

The key distinguishing characteristic is the fact that every git checkout contains the full repo history and metadata. This means a consistent network connection to the master server isn't necessary. In fact, it means that the concept of a "master server" itself isn't necessary. With Git, you only need to connect to other servers when you pull down changes or when you want to push them back up to the remote repository. You can happily commit, branch, revert, check out older revisions, etc. on just your local checkout without needing to care about what's going on with the remote server. Even if you treat your remote repo on GitHub as your "master", it's still a far cry from the way that centralized VCS works.

If you've never worked with true centralized VCS, it's easy to take this for granted. Working offline with a system like Perforce or SVN is technically possible but considerably more involved, and most people avoid doing it because it puts you far off of the beaten path of how those systems are typically used. It basically involves you having to run a local server for a while, and then later painfully merging/reconciling your changes with the master. It's far more tedious than doing the equivalent work in Git.

Now, it's important to note that Git's notion of "every checkout contains all the repo data" doesn't work well if the repo contents become too large. It's for that reason that things like sparse checkouts, git-lfs, and VFS for Git exist. These sorts of extensions do turn Git into something of a hybrid VCS system, in between a true centralized and a true decentralized system.

If you want to understand more, here's a great tech talk by Linus himself from 2007. It's of note because in 2007 DVCS was very new on the scene, and basically everyone at the time was using centralized VCS like SVN, CVS, Perforce, ClearCase, etc.

https://www.youtube.com/watch?v=MjIPv8a0hU8

Git is a DVCS though. Just because GitHub exists does not exclude Git from the category of a DVCS. You get a local copy of the entire history with Git which is what pushes it into that category, nothing to do with GitHub. SVN is centralized in the sense that you are not grabbing the entire copy of the repo locally. Not academic differences.

Git is a DVCS, and GitHub uses Git, so it's a DVCS because I can clone locally. GitHub is a central location, that's true, but I can still have my local clones, and I can host my own forks locally, anywhere I want, at a GitHub competitor, under multiple GitHub orgs / users, whatever. So, yes, it's a DVCS.

I'm curious how you come to this conclusion. GitHub has always had fairly insane hosting problem sets. When someone clones the Linux repo, that's like 5G in one go. The full clone issues and the problems of a few edge case repos create sometimes crazy hosting costs and scaling problems. Most centralized systems only have to deal with one working tree or one delta at a time. There is not much that goes over the wire in centralized systems in general, comparatively.

Multiple other distributed version control systems in the 2000s had support for easy hosting. Darcs was actually the best in this era, IMO, because it was far simpler than both Hg and Git -- a Darcs repository was just a directory, and it supported HTTP as the primary pull/patch sharing mechanic. So, you could just put any repository in any public directory on a web server and pull over HTTP. Done. This was working back in like 2006 as the primary method of use.

In any case, the premise is still wrong because as mentioned elsewhere, the distribution of repository sizes and their compute requirements are not smooth or homogonous. The cost of hosting one popular mirror of the Linux kernel, or a project like Rails, for 1 year is equivalent to hosting 10,000 small projects for 100 years, in either SVN or Git. The whole comparison is flawed unless this dynamic is taken into account. GitHub in 2024 still has to carve out special restrictions and exemptions for certain repositories because of this (the Chromium mirror for example gets extended size limits other repos can't have.)

Git also lacked a lot of techniques to improve clones or repo sizes of big repos until fairly late in its life (shallow + partial clones) because 99% of the time their answer was "make more repositories", and the data model still just falls over fast once you start throwing nearly any raw binary data in a repository at any reasonable clip (not GiB, low hundreds of MiB, and it doesn't become totally unusable but degrades pretty badly). This is why "Git is really fast" is a bit of a loaded statement. It's very fast, at some specific things. It's rather slow and inefficient at several others.

Why didn't mercurial win then? There were almost a dozen other distributed version control systems built in those early days, most of which I cannot remember but all had the same distributed ideas behind them and should be been as easy to host (some easier).

>imagine an alternate universe where the founders of GitHub decided instead to found HgHub.

I'm reading this as "HugHub" and audibly laughing!

Git really does need a commit header to track the original commit.

> After using hg which doesn't have the concept of an index, I realize I don't miss it and the user experience is better without it. Seriously, even thinking about it is unnecessary mental overhead

... for some people. I know a substantial audience who believe $(git add -a) is The Way, and good for them, but if one has ever had the need to cherry-pick a commit, or even roll back a change, having surgical commits is The True Way. JetBrains tools now even offer a fantastic checkbox-in-the-sidebar way of staging individual hunks in a way that only git-gui used to offer me

I just had a look at $(hg add --help) and $(hg commit --help) from 6.8.1 and neither seem to even suggest that one may not want to commit the whole file. I'm glad that makes Mecurialistas happy

>I doubt there is a big enough market of anarchists for Github to even bother worrying.

A lot of people writing prorietory code bases would definitely use it.

I don't think a founder wants the startup's codebase to leak via an LLM?

It’s already feasible with Keybase (although I wouldn’t trust them any more, because of the Zoom debacle).

>Everything you're asking for is available today in self-hosted services

There is a reason why people use hosted Git services it's not practical for everyone to "self host".

We can run a self hosted Signal app for privacy. But it's neither convenient nor practical for everyone.

Generally people mean "E2E Encrypted" as "the hosting service cannot see it". Git-over-SSH does not achieve this, it just encrypts in transit.

> really there’s little reason to use it for private repos

Admin costs? I paid $7/month to github for years for private repos (atm private repos are free so i switched to not paying when the card i was using acted up and i couldn't be bothered to fix it). I'm sure the time I would have spent admining a ssh based server would have cost more, even at 1 hour/month.

Plenty of large companies. The risk is much higher that an individual's computer gets compromised, which often has a lot worse than just source code.

Branching in Subversion was fine, but merging was quite painful (at least at the time I was using it, around 2008ish). From my recollection, SVN didn't try to figure out the base commit for a merge - you had to do that manually. I remember having a document keeping track of when I branched so that I could merge in commits later.

And even if I was using it wrong or SVN improved merging later the fact was that common practice at the time was to just commit everything to the main branch, which is a worse (IMO) workflow than the feature-branch workflow common in git.

But you're right, SVN was largely fine and it was better than what preceded it and better than many of its peers.

Edit: Forgot to mention - one of the biggest benefits to git, at least early on, was the ability to use it locally with no server. Prior to git all my personal projects did not use version control because setting up VC was painful. Once git came around it was trivial to use version control for everything.

Subversion was great up until your working directory somehow got corrupted. Then you'd be in some kind of personal hell cleaning it up.

And honestly, it was always a pain in the ass setting up "the server". Unlike with git you needed a server / service running 24/7 upon which to check your code into. Which was always a pain in the ass at home... needed to keep some stupid subversion service running somewhere. And you'd have to go back into that service and remember how to create new projects every time you got a wild hair up your ass and wanted to create a new thing.

Git you just do "git init" and boom, you have a whole complete version control system all to yourself with no external dependency whatsoever.

That being said, TortiseSVN was the best GUI for version control ever.

Subversion didn’t get working merge support until years after git. Like CVS it basically required trunk-based development. Feature branches were not supported. You needed a separate checkout for any work in progress. You could not checkpoint your work with a commit before updating to the latest head. Every update is a forced rebase. It sucked.

CVS was absolutely not oriented around locking files.

It was about merge and conflict resolution like SVN or Git.

VSS was oriented around locking. And also broke all the time. Oh, and also lost data... And oh, it was also the expensive one used by everybody that kept saying "you get what you pay".

One thing that Git and the other DVCS's massively improved over Subversion is that commits are local, and you only need to talk to a remote endpoint when you push/pull. In Subversion, every commit would require uploading changes to the repository server, which encouraged larger commits (to amortize the overhead).

This was not my recollection. The big thing about git over subversion at the time (at least before everyone started putting their repos up on github with pull requests and all) is that it was truly distributed i.e everyone maintained their copy of a repo and no repo was the 'master' or privileged source of truth. And merging changes was/is relatively seamless with fine grained control over what you want to merge in to your copy that svn simply didn't provide. Svn on the other hand is a server/client architecture. Although you could have multiple servers, it was kind of pointless as keeping them in sync was more trouble than it was worth. For most workflows there was the server or master repo and your local copy is not under source control. And if that master/server should go offline for any reason you were not able to 'check-in' code. I remember this being such a pain point because if the master was offline for a significant amount of time you essentially had no way to track changes you made and it would all just be one big commit at the end (which was also a major pain for the administrator/repo maintainer who would have to merge in a whole bunch of big breaking changes all at once). Maybe git vs mercurial was a close fight with no immediately obvious winner, but subversion's days were pretty much numbered once git showed up.

I never had the time (thankfully) to get good at Subversion. But now that I’ve “internalised [the pain]” of a DVCS I could never go back to a centralized VCS. Interacting with a server just to check the log? Either promiscuously share everything I do with the server or layer some kind of second-order VCS on top of Subversion just to get the privilege of local and private-to-me development? Perish the thought.

SVN is fine as long as you don't have multiple people editing the same file in the same time. In that case, generally one person gets his work overwritten. Committing on SVN is basically the equivalent of "git push --force".

Git clients became popular interfaces to SVN. This is how the organizations I was at moved from svn to git -- we/devs started preferring git locally and eventually migrated the backends to match.

Git's been around for almost 20 years now. I would say fairly dominant for 15 or so.

Git is overrated for a DVCS. But it’s not overrated considering the old-school competition like SVN.

The assumptions of SVN makes it feel like a dinosaur now.

Already in 2010-2012 majority of projects I encountered were using git. Last time I saw an SVN-based project was in 2015, before I migrated it to git.

I have to agree on the cult aspect. This is unfortunate because better tools exist already today, but lots of people refuse to even entertain that possibility.

sr.ht doesn't go for "fun" but brutal minimalism as their main selling point.

I agree with this take, I think hg could have overtaken git for a while, but git catered a bit better to the OS communities and hg catered a bit more to big companies from a DX perspective. Maybe in this case, the important thing is knowing that your partners/technologies are aligned with your vision of the future- git has been more open-source first (I would argue)

The article uses "taste" pretty broadly compared to many folks in the comments. First mention is about the site being pretty. But later he says "We had taste. We cared about the experience" which more aligns with your perspective of convenience.

I was a late adopter, also, and git is definitely not perfect. Mercurial did some things better, and at the time, notably, the forest extension. Git's flexibility is a two edged sword and the history rewrite footguns should be harder to use. Git does comes close enough to solving a fundamental problem it will be very, very durable, though. As long as it is used for linux kernel development I expect it continue to be the dominant dvcs.

I think that if github hadn't come out something other than git would have one. While git did have Linus behind it, the others were objectively better in some way and working on the areas they were objectively worse, and eventually the advantages would have got everyone to switch. However the others never had anything like github - even 20 years latter they still aren't trying (rumor is they are not dead)

I worked for CollabNet from pretty early on. CollabNet had one major customer... HP. Everything got developed for a relatively stodgy old customer. They wanted centralized version control. They wanted tons of ACLs. It all was very corporate sales focused.

Github "won" because they were not CollabNet.

I'm not GP, but I firmly agree with the observation. I also readily admit that I'm for sure biased because I was on GitLab before GHA was even a dream in someone's eye

The hazard to "prebuilt workflows" is that one needs to know about them, and load their assumptions into your head before using them, which can be true of any sprawling namespace but tends to be less true within a single organization. That's not even getting into the risk of folks who do both things: copy-paste someone else's "uses:" statement eliding the version pinning because "what's the worst that can happen," amirite?!

As for the "for terraform, AWS, k8s" part, that is 110% why I am a GitLab fanboy because the platform natively speaks those technologies - I don't need to (deep sigh) set up an S3 bucket with a DynamoDB to have Terraform State - it ships with GL. I don't need to do crazy "uses:" with some rando shit to use AWS federated credentials, it ships with GL. I for sure don't need to do crazy "uses:" to have k8s rollouts, rollbacks, status checks, and review environments: they are built-in concepts in GLCI

Also, unless something has gravely changed in the past little bit, how in the universe can anyone use GHA with a straight face without "show me the expanded and linted version of this yaml" as with https://docs.gitlab.com/ee/ci/yaml/lint.html#simulate-a-pipe...

I'll fully admit that $(gitlab-runner exec) is a cruel joke, but every time I hear someone claim that Act (or its like 50 forks over in Gitea/Forjeho-land) are "local GHA" I throw up in my mouth, so I consider that pretty much a wash

---

ed: I realized this debate is also very similar to the Maven-vs-Gradle argument: do you want executable junk in your build process, or do you want declarative steps? I am firmly, 1000000000000000000% in the Maven camp, which also explains why the last thing I want is some minified .js files someone else wrote to be injected into my CICD process

I wish they even had some official statement as to why this hasn't been implemented yet, but from what I can tell, basically nothing has been said about it

From the paper

> "The database contains data from January 1990 until May 2007. Of this time horizon, we analyze the time frame from January 1995 to December 2006. We omit data before 1995 because it is too sparse to be useful"

> "Large distributions like Debian are counted as one project. Popular projects such as GNU Emacs are counted as projects of their own, little known or obsolete packages such as the Zoo archive utility are ignored"

So even though methodology is "very specific", it seems very incomplete/ inaccurate/ selective. Even Linux kernel, as per their source, started in 2005 (https://openhub.net/p/linux).

Source: https://www.researchgate.net/publication/45813632_The_Total_...

Did $100M investment help Github to win, or had Github already won in 2012 with profitability and 3M git repos?

Agree but my point is when you see a new and better rival then instead of pivoting SF became even worse and became malware-ised.

Also SF was based on SVN. They failed to understand and capitalize on a better tech on the market i.e. git.

So in exchange for a little speed we are stuck with one of the most user hostile tools out there. That's not the deal I would have wanted to make. The interface is atrocious as some switches change completely what the command does -- this was partially acknowledged and fixed in git switch but there's so much more, it loses work way too easily and some of the concepts are near impossible to grok. (I did learn git eventually but that doesn't mean I like it. It's more of an uneasy truce than a friendship.)