Why doesn't Facebook use git? 

There's someone at the door 😶‍🌫

Stop it subconscious

Same…

come over i have one

Night night

Thanks bro

maybe add that the git maintainers at the time were not the most cooperative in helping out fb to address the performance issues which resulted in fb adopting mercurial again

Real MVP.

Also, FB Engineering uses stacked diffs, which are the norm and recommendation with Mercurial, but not with Git. The sponsor Graphite implements stacked diffs for / on top of git.

That and it supports diff stacking which git doesn't

I'm the lead developer at my company and I refuse

Facebook seem to have a tendency to try to idiot-proof their tooling.

Of course, but at least this is possible!

The other teams can review the parts they're responsible for in your PR, but at least with a monorepo, the whole feature is an atomic unit that's either present or missing. With distributed repos, you can have different versions of each component, and it's possible that one component supports the feature, but the other doesn't, breaking things. So you need to build version management on top of it, which adds complexity.

Yes, that is true. However, you don't loose this in a monorepo. If you want, you can still make changes just in one part and wait for someone else to do his part. In a monorepo, you gain the ability to potentially do changes in all parts and sevices of the software. And it can also be much easier to work together with other teams. You can start a branch, start doing the changes you need, and before you are completely done and it's completely working, the frontend dev can come along, grab your branch and start the project on his machine, can start implementing stuff. Then, it depends a bit on your workflow, but potentially, you could make a PR with the combined changes to update everything at once, without needing to worry about breaking your staging temporarily. Even better, when doing changes elsewhere, you can run your build, run your tests, etc and see unexpected issues earlier. The alternative is, you update a project, it gets published to your company's package feed, you pull the package in your other projects, down the line you notice something broke somewhere, you do fixes in the first repository again, pull updates again in other repositories, see that sth else is broken now, and so on. It's just so much more annoying and time consuming.

As a game developer (who worked at AAA too), Perforce is pretty much universally hated by the whole industry. It's not used because it's good, it's more like OracleDB (very specific and hell to migrate)

​@@krisitof3 Facts... I hate OrcaleDB. Currently using it on a project I'm working for contract. Currently my personal company started working on a game. After 12 years as a software engineer pivoting into game development as I always wanted to do. But never touch your heart of perforce. Currently using Mercurial because the last project I was working on for about 9 years in Mercurial. For me and the team that I'm leading it's out of familiarity.

never heard, is it VC for source code or assets as well

Perforce may be more agile now, @@Special1122 , but when I was considering it, alongside Git, Mercurial and Bazaar, to replace VSS, in the noughties, it felt very old school.

Yeah, if I understand the timeline correctly, it looks like mq (mercurial queues) predated Facebook involvement in the project.

Like most people use CLI anyways. If anything if it is posible to make so many GUIs for CLI app why in the world doesn't someone make custom CLI front end for those tools. You like Mercurial CLI but need to use git, use Mercurial commands for git.

That really surprises me. Even after 14 years of using git, I'm appalled by it's terrible default merge heuristics. I long for the quick and simple merges of my mercurial days. Even now, when merges get difficult, I pull out kdiff3, the default Mercurial merge tool, and it makes complex git merges *so* much easier.

The GIT CLI is so bad, you have to literally browse the GIT source to learn to actually use it properly.

​@@Bozebounfortunately true. Hence why I have so many GIT aliases

Alienbrain perhaps.

*was using The're phasing out mercurial in favour of git.

@@isaactfa it's true that they've been migrating to git for a while now, but it's mostly because newer developers don't know anything but git, and official firefox docs still point to hg repo

He said back in the day svn was one of the big 3. Svn is still wildly used. Svn came out only 4/5 years before git.

@@isaactfa Look at the state of mozilla right now, I don't think version control should be a priority.

You forgot to mention: Linus had tried mercurial, but mercurial didn't scale for the Linux kernel at the time, so git was created.

LOL

nah man, browser extensions sus

@@syedmohammadsannan964 every heard of open-source?

@@syedmohammadsannan964 what's wrong with it mane?

@@__--red--__ They can spy on you or hack you as much as they want, and no guarantee of them not doing so. Unlike apps from say, the Google play store or app store, where Google and Apple both carefully review the apps posted there and getting viruses from apps downloaded from them are rare. On the other hand, Chrome extensions are almost completely unregulated in every way. You would have no idea that an extension used by 10K people with 4.9 star reviews is spyware or not.

Git is complete insanity.. No wait, I meant: Git is complete insanity... The third dot is very important!

What is also interesting to mention, if Mercurial had scaled at the time Linus needed it for the Linux kernel, he would have used Mercurial.

@@autohmae Exactly. Totally sad story for the Mercurial author, such a beautiful tool and then this. github then was the nail in the coffin

Same here. I still use Mercurial for all my personal problems, because it is just so much nicer to use, and can only work well with git at work thanks to magit.

Yes. git is capable, but lovable? Depends.

Agreed, the use of topics are essential to multi-repo workflows, ensuring changes to a dependency doesn't break things using it.

Where I work once had a monorepo in svn. Merges were a nightmare. I remember merge reports that were so long they kept breaking Confluence. When we moved to git, we split out the project into dozens of repos, with a complex system to deploy all of those repositories, and a gerrit review system to keep to make sure changes in one, didn't break another. Merges were easier, but we had many more of them. When we moved away from the arcane orchestration system we were using, to using maven, we started coalescing those repos back into something closer to a mono repo, as dependencies got increasingly difficult to manage. Now, we rarely commit to more than two or three repo's depending on which project we support.

I think its the Arc Browser for Mac, (Beta for Windows)

Mercurial, git and Bazaar were the pretenders to the throne, but Mercurial, git and svn were most commonly talked about in those early days, unless you were part of a few very specific communities. CVS's popularity was already waning, and my first VCS (RCS) was thankfully no longer anywhere to be seen.

I do agree that _flexibility_ is a powerful tool. many small repos do not lend themselves to being flexible, monorepos don't take away any paths to production from you.

⁠@@seannewell397honestly asking because we’ve been having the same discussions at work recently: how do many smaller repositories not contribute to flexibility? How is a large monorepo, conversely, more flexible? We have so many architectural & engineering principles that show modularity - generally speaking - has less cognitive complexity, is more maintainable, is more flexible & easier to change, easier to test at a low-level, separates concerns, supports encapsulation, etc etc…. And we see how these principles manifest themselves in things like shared libraries & packages that I pull in to a project instead of keeping all of that code in my own codebase. Or how large monolithic programs are less optimal for all of those reasons compared to modular programs, except where other concerns like maybe performance is critical. I’m still trying to wrap my own head around the apparent contradictions between writing small, modular, loosely coupled code but using a huge monolithic repository that co-mingles it with everyone else’s code and takes away my code’s fine-grained version control. The workarounds for most of these problems just go back to simulating smaller discrete repos like using a codeowners file to prevent others from modifying my code in the monorepo’s subdirectory. Lol… It really just seems like we enjoy going around and around by rehashing & relearning the same concepts & pitfalls over and over again. I dunno.

That's why feature branches are a thing, you have offshoots from that for the smaller PRs but the feature remains one cohesive unit until it's ready to ship

@@TurtleKwitty trunk based development with features hidden behind flags is a much better system imo. If feature branches are too long-lived, merge conflicts become inevitable.

@@AZaqZaqProduction and add huge file sizes on top, you get conflict and you don't even know was that line supposed to be 200 lines below.

Was going to mention Google. I know at least chromium was and probably still is on mercurial

@@kienanvella Since chromium is open source it actually doesn't use the Google internal tooling. It's just git with gerrit on top. The internal projects at Google "kinda" use mercurial as in they have a mercurial-based client but there is a ton of custom code around it.

fig (google's mercurial version of git) and critique (Google's pull request tool) are so much better than GitHub. I recently (at the start of this year) left Google to join a startup, and man, do I miss fig.

This 100%

Very good question! I have two answers, "how most do it" and "how I do it" How MOST do it: Build automated CI/CD, point clients at 'versioned' servers, leave old servers deployed for X amount of time (see: "skew protection") How I prefer to do it: Server the frontend THROUGH your backend, so the server generates the "most current" client on every request

@@t3dotgg Why on every request? I mean I know what you mean but it sounds like build the thing on every request xD

Mono or multi repo makes literally no difference to that problem whatsoever?

@@t3dotgg Thanks for your reply! Maybe you could do a video on the "deploying monorepos" topic? That would be awesome! After watching this video, I tried searching for it, and I didn't find anything. I'd be curious to know more about how the versioned builds/servers work, how they rollback (I mean, if you rollback the server, the client might hit a dead endpoint, or some old endpoit which is not compatible, because the breaking change is not there anymore), how long the "old" servers are kept running, how the CI/CD avoids redeploying the services that didn't change, how often they deploy (they probably have thousands of merges every day), etc. On a much smaller scale, I believe Vercel/NextJS does something like this. I mean, a single NextJS repo is basically a monorepo (api folder + frontend), and vercel generates new deployments on every push, including preview/testing ones. And I'm curious to know more about your preferred approach as well. Would that work for an SPA?

Git alias help a ton

Surely it's generally "horizontal" not "vertical" (though quite likely vertical in terms of networking and that's the mistake people make not using a monorepo because they think every svc needs an entire repo). You don't have a different prod and dev repo do you?

@@Bozebo I worked on a project where they had, I think 5 front end apps, which for the most part had a lot in common and a shit ton could have been reused. You could not have people from one app switch to another as it was that much different structure.

Is that like git modules or git subtrees ?

This is the thing. Although there is a suggestion that the stack can be a branched graph hinting at another feature that would be maybe a bit harder to replicate simply with git. Not impossible. One way to do it would be to have a featureA and featureB branch and then branch off of one of them e.g. featureA creating featureC and then merge featureB into featureC. And here we go, we have a stacked diff workflow. I suspect meta built more tooling around stacked diffs to facilitate it easily, but it can be feasibly replicated in git.

Coincidentally we tried stacking workflow without even realizing it when a developer just created a new branch off an existing branch that's awaiting PR review (because the new feature is dependent on it). It became a nightmare when we approved the review and squashed the PR. Now the new branch, even when rebased, would duplicate all the commits from the original PR even if those diffs were squashed into a single commit. Without a highly focused developer training covering "interactive rebase", this is not an easy situation to fix. The second PR for the new branch erroneously shows all the commits from the first PR even though none of those commits contribute to the overall diff of the second PR at all. Conclusion: Git is not designed for stacking workflow.

that's pretty sad. i think this behavior is something ingrained in the Linux community

Just a classical skill issue. They don't know how to use the tool properly so they blame the tool.

I've tried to promote the use of submodules many times at work, but they are quite a blunt tool, and every time I've tried, I've faced pushback.

Mercury is after all, very mercurial, as is software development. *8')

This. It seems they never heard of this...

Depends. It's a commercial solution so I doubt most gamedevs use it, maybe some big game studios do. Git LFS seems to do the job for most.

Game devs also use C++ and "fat IDEs" like visual studios. Not everything the cool kids do works for us nerds ;)

Perforce is good at managing binary files, common in game development.

@@elirane85 VS's C++ debugger is insanely good. I've never seen any C++ vscode setup that comes close to Visual Studio's functionality.

@@nikkehtine Perforce is considerably more preferred over git + lfs in the game dev industry. From my experience, the fact it's a commercial solution doesn't play much impact in the conversation of viability. git + lfs still has a lot of complications over perforce for game dev, especially for larger games. That said, I personally don't like perforce, and using it felt really clunky and unintuitive for the years I've done game dev with it.

"I tried explaining we can still do microservices with a monorepo but they don't listen lol." I've been there. Apparently engineers don't know what a directory is!

Yes.

git modules are a nightmare when anything goes wrong. In the free software projects where we had used them, we painstakingly moved away again, because they broke too hard when something was wrong. Missing robustness. Except for one where we had to re-introduce that, but that’s just a shell repo with some github actions.

I don't think so. Functionalities can be implemented with kernel modules.

Oh god. I use it at work for some repos and I have to disagree. OOTB it seems nice but you quickly miss many git features and run into many nuisances.

@@WHYUNODYLAN Dang, I am sorry to hear that. Are the devs aware of the missing features?

@@WHYUNODYLAN Maybe it's because you're used to git way of work? When you pilot stuff, try to embrace solution as whole.

@@Dhalucario The fossil devs? Yeah, sorta. The main difference for version control is that fossil doesn't allow rewriting of history, which is very intentional. I do a lot of weird stuff with my repos so that's already a fairly big nuisance for me. However, I sorta misrepresented my point because the other features I prefer in git, well, they aren't actually to do with git. Fossil is a whole "project management" system--issue tracking, wiki pages, etc. So it provides the same stuff as e.g. Github, but, frankly, it's not as good as what I'm used to. For instance, there's no concept of pull requests so at work we have to perform code reviews in Jira tickets. Fossil devs consider it to be more "featureful" for having this stuff built-in, but it's also very restrictive, since you can't jump between tools like you can with Github/Gitlab/Codeberg.

@@d3stinYwOw I could maybe agree with this if we were able to lean into fossil fully. We still have to use a whole bunch of other tools for project management, so we only use fossil as a VCS system. That being said, I think I'd still much prefer something like Forgejo if we were to go the route of "one tool for everything".

I dont have a definite answer but i have my suspicion that it goes down to this: i have worked a lot with the embedded freeRtos, which, in a way its a simple OS kernel. Its a collection of usefull primitives, classes, system calls etc, the log system, and some drivers. While large, its mostly low level without a huge amount of boilerplate stuff. On the other hand consider the typical web app using react (or anything really). You have backend code with a million database procedures or an ORM, frontend with a million dependencies, css, js etc etc. From the get go you have a difference in scale with the empty webapp to be larger than the whole FreeRtos. So i guess its something like that, just in a different scale

@@GeorgeMixalis That's certainly a possibility. And if it is just down to code bloat, then the monorepo is a bad idea because they should probably be paring their codebase down a lot instead.

Kernel is highly optimised and specialist. Whereas business software tends to be as intentional and obvious as possible and more able to quickly change. Kernel is also helpinng provide "primitives" allowing everything else in the OS to emerge more complexity, whereas business software is high level human ideas and all their vast nuances.

Linux kernel is supposed to be small. Most Customer and business software systems are larger than Linux heck even Chrome is larger than linux

@@randymccoy8097 The problem I'm having with it is, what does Facebook as a company do that in a single repo they would have more source than Linux. I would think that a social media company wouldn't require that much code for even the backend of their website. It feels very much like corporate bloat, and that's the only way it can make any sense to me.

The tooling does that for you, but yes behind the scenes that's what happens.

I feel like I understand it, but I also feel like I don't know how I'd work with it. Like someone describes to me how to drive a car, you get in, pull the parkingbrake, check mirrors, release the brake, slowly release the clutch and accelerate slightly. That's the feeling I have, I have it described how to drive a car, but I don't know how to drive a car.

I use stacked diffs (in git) to break a widespread change into comprehensible steps. If you were just faced with the overall diff to hundreds of files it would be overwhelming, you wouldn’t see the wood for the trees. For example, show the kernel of the change in one or two files first to demonstrate the concept and then show the same change applied to all files. Meanwhile only when it’s applied to all files can you test the final change.