5 ms·

> 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 worke

by bsder 2y ago

> 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.

chris_wot 2y ago
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.
- jsmeaton 2y ago
  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.
  - oooyay 2y ago
    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.
    - fragmede 2y ago
      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.
    - immibis 2y ago
      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.
      - CRConrad 2y ago
        No, GitHub won because of git, lots of VC (later MS) money, and brilliant marketing that makes people think "Git won because of GitHub".
    - jmmv 2y ago
      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.
    - cruffle_duffle 2y ago
      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.
      - silisili 2y ago
        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).
        medstrom 2y ago
        You mean the comparison is too mild? https://www.merriam-webster.com/dictionary/harsh https://www.merriam-webster.com/dictionary/harsh
        silisili 2y ago
        Oh, meant harsh to Myspace, which wasn't that bad really.
        phatskat 2y ago
        I read it as harsh to MySpace, because that was very unfair to MySpace imo
      - darkwater 2y ago
        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.
      - 2y ago
    - bsder 2y ago
      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.
      - mardifoufs 2y ago
        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.
        bsder 2y ago
        > 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.
        duggan 2y ago
        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.
    - Suppafly 2y ago
      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.
      - CRConrad 2y ago
        > 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".
  - CRConrad 2y ago
    > 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.
- inkyoto 2y ago
  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.
  - protomolecule 2y ago
    > 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 https://svnbook.red-bean.com/en/1.5/svn.basic.in-action.html
  - rstuart4133 2y ago
    > 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.
gumby 2y ago
> 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.
- KronisLV 2y ago
  > 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.
  - phatskat 2y ago
    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.
- throw0101c 2y ago
  >> 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.
samatman 2y ago
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.
- Mtinie 2y ago
  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.
  - dgfitz 2y ago
    Which is such a tragedy. Hg is such a simple pleasure to work with.
- CRConrad 2y ago
  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.)
treflop 2y ago
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.
- Uvix 2y ago
  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.
  - HdS84 2y ago
    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.
    - Uvix 2y ago
      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.)
- foundthebeef 2y ago
  GitHub won because it was free.
- fijiaarone 2y ago
  If git doesn't need a server, then why do you need Github?
foundthebeef 2y ago
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?
- fijiaarone 2y ago
  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.

by bsder 2y ago

chris_wot 2y ago

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.

jsmeaton 2y ago
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.
- oooyay 2y ago
  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.
  - fragmede 2y ago
    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.
  - immibis 2y ago
    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.
    - CRConrad 2y ago
      No, GitHub won because of git, lots of VC (later MS) money, and brilliant marketing that makes people think "Git won because of GitHub".
  - jmmv 2y ago
    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.
  - cruffle_duffle 2y ago
    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.
    - silisili 2y ago
      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).
      - medstrom 2y ago
        You mean the comparison is too mild? https://www.merriam-webster.com/dictionary/harsh https://www.merriam-webster.com/dictionary/harsh
        silisili 2y ago
        Oh, meant harsh to Myspace, which wasn't that bad really.
        phatskat 2y ago
        I read it as harsh to MySpace, because that was very unfair to MySpace imo
    - darkwater 2y ago
      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.
    - 2y ago
  - bsder 2y ago
    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.
    - mardifoufs 2y ago
      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.
      - bsder 2y ago
        > 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.
        duggan 2y ago
        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.
  - Suppafly 2y ago
    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.
    - CRConrad 2y ago
      > 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".
- CRConrad 2y ago
  > 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.
inkyoto 2y ago
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.
- protomolecule 2y ago
  > 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 https://svnbook.red-bean.com/en/1.5/svn.basic.in-action.html
- rstuart4133 2y ago
  > 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.

gumby 2y ago

> 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.

KronisLV 2y ago
> 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.
- phatskat 2y ago
  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.
throw0101c 2y ago
>> 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.

samatman 2y ago

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.

Mtinie 2y ago
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.
- dgfitz 2y ago
  Which is such a tragedy. Hg is such a simple pleasure to work with.
CRConrad 2y ago
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.)

treflop 2y ago

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.

Uvix 2y ago
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.
- HdS84 2y ago
  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.
  - Uvix 2y ago
    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.)
foundthebeef 2y ago
GitHub won because it was free.
fijiaarone 2y ago
If git doesn't need a server, then why do you need Github?

foundthebeef 2y ago

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?

fijiaarone 2y ago
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.