Why Facebook Doesn't Use Git 

Never heard about this react framework called git

GIT is hard for people who hold branches for months and then they're surprised that the merge conflicts will take weeks to untangle.

I started working at Meta (called Facebook then) in 2014. We used Git then. The sauce at the time was that we switched to Mercurial because although neither Git nor Mercurial could scale to our needs, there was a lot more friction upstreaming our scale patches to Git than to Mercurial. And we didn't want to maintain our own fork.

Git is probably confusing due to a lack of context around the problems its trying to solve. The entry level user is just trying to check out and save progress. The only tools they need is to be able to create backups and download files. Then they're introduced to a complicated tree system and CLI designed to solve a series of problems relating to group development over time and space with steps like staging and branching.

Git is easy, until it's SUDDENLY confusing. I've called in the cavalry to resolve a weird merge more times than I can count.

"Reverse engineered the bitkeeper protocol" He telneted to the bitkeeper port and typed "HELP".

I'm a senior engineer who often helps new people understand how the team uses git. From my experience, the biggest surprise to people is that there are actually three versions of a file (typically), not just the local one and the remote one (the paradigm for Perforce and Subversion). It is the fact that the local "index" contains a checked-out version which is certainly different from local edits but possibly ALSO different from the latest revision on the remote branch that causes the most difficulty.

Git is brilliant in that they can take common version control terms and make them do something else.

At the time, there was a fundamental difference between Git and Mercurial whenever thinking about large mono-repos. In Git, the storage (in the .git directory) and file system is considered part of the spec. On the other hand, Mercurial has the concept of a virtual file system. A company that would like to use Mercurial could implement their own VFS that knows what files were modified and expose this information to hg. Things changed a lot in the last 10 years.

I can't believe throughout this entire time, nobody mentioned Sapling, which is the SCM currently used by Meta and is as a matter of fact (let's huddle so no one can hear it) written in Rust.

Interview Steve Yegge. His hot take is that Google's internal version control stuff is light years ahead of Git. So it wouldn't necessarily be an upgrade for Google to move to Git as you suggest.

What I’ve found is, and currently dealing with it at my company is, the subset of engineers who find git hard are also the subset of engineers who, if given the chance, would never use source control and don’t care to learn anything about source control. Maybe shit take? But source control to me is the most important tool, if you arnt willing to learn how your source control system works, your a bad engineer.

Git has the reputation of being hard for two reasons (I'll let you juge their validity): - You *have to* learn it. You can't just wing it. You can't just google the commands and learn on the way. You have to dedicate some time learning the underlying concepts like: commit, branch, remote, tag, index (or stagging area), working directory and so on. - The commands are names can be confusing. 'rebase' does more than changing the base, it peels off commits (diff+message) and reapply them... possibly on another branch (changing the base), possibly at the same place but making changes along the way. 'reset' might change the working directory, the index, the current branch or all three of them depending on the options. 'checkout' is used to switch branches, but also to retrieve the file of a given commit into the working directory. There are so many more confusing commands, I can't name them all.

Came here for the tech history, stayed for chat being flabbergasted by git

Never heard of stacking before so I looked it up. There was a lot of text that basically came down to: Keep working on new features by branching off your feature branch while it‘s sitting in PR review instead of main and then rebase to main after the PR is done. They may use different words but that is what you‘d do in git - and we actually do at work. We just never thought of giving it a name…

I know Git well, but there are two things that I know people around me find confusing (the latter still confuses me): 1) The difference between the three levels of working and staging area and repo - and when to use "reset" and "checkout" to get the sought version of the file 2) The switch-around of "HEAD" and "incoming" in conflict markers during rebase (fast-forward), and the following "theirs" and "ours" - I know that a rebase (fast-forward) is basically a series of cherry-picks onto the target branch, but it would be much easier if the conflict markers would indicate which branch they belong to, to give better context.

GIt is not hard, I think the problem is many of the features are really only useful for large scale distributed projects (like the kernel it was written for), then someone sees a feature they really don't need or shouldn't use and decides "this will solve my problem!". Then they have two problems, then instead of backing things out they start doing insane things to make the feature work the way they want it to work. I watch people do this *WEEKLY* across several projects at several different customers, FOSS code, non-free code, and stuff like configs, dot files etc..

Git: Created by Linus Torvalds, Git's initial release was on April 7, 2005. Mercurial: Created by Matt Mackall, Mercurial's initial release was on April 19, 2005. I first used Mercurial and learned later about Git.

Tech corporations making cringy nouns for their employees is so awful.

I thought I had watched the exact same video before but then remembered it was Theo’s video about the same article!

git is difficult just cuz of all of the jargon. I remember at work I was trying to do a git revert. I grabbed the relevant commit SHA, I first tried it on a merge commit, but a merge commit has 2 parents so you have to specify an index, how do you know which parent to target and they are indexed, how do you know which index corresponds woth which parent. after some research I found that I actually didn't need to revert the merge commit and just had to revert a couple of other commits. I also only wanted 1 commit message so I had to add a flag to each revert for that. I was able to accomplish what I wanted but required some time learning. I can see the perspective of not wanting to properly learn a tool like git that functions sort of as a means to an end.

"Never taken the two hours of time it takes to learn git well enough to not be confused by any of it" This is in fact, the concise explanation you were looking for. We're so adapted to how git works at this point we just accept that taking two hours to learn it is reasonable, rather than iterating on it's core to improve it's usability with an aim to get that onboarding time down to a minimum. Instead we've decided pass that responsibility to a handful of third party websites that have grown to dominate the industry.

5:28 - "People dont learn so its confusing to them? Thats a stupid reason!" 5:58 - "It's because you've never actually learned it" *Wtf* he just agreed with the "stupid reason"

git is not hard the issue is it is built with language that makes it confusing to a new user.

The few times i tried to explain why i use a git clone instead of the .zip version of the same project it usually goes into they find it easier to use a zip file then to type in command prompt or into terminal. For why i use git? Git pull is quicker then having to redonwload then decompress an entire zip file of the same code.

I would be super interested in knowing more about this "stacking" approach vs "diffs" mentionned at the end of the video.

Maybe it's not that Git didn't care about supporting large repos, they just didn't see it as a priority then. This happens in SaaS all the time, e.g. ABC Corp wants to use your SaaS product but they need feature X, but you're not ready to develop and support feature X yet.

I had a bit of GIT heartburn when I first came to my current employee, as previously I had only used: VSS, CVS, and SVN. After using it for a few months and we had moved away from a mono branch approach, I finally understood wtf it was trying to do.

I do hate AirBNB linting rules for JS, because teams adopt it as it was the bible where it is just a pain in the a**

I started to work with SVN for a brief period of time. Then switched to that Microsoft VC app called TFS and didn't like it. I was reluctant to switch to GIT because of the same reasons people are posting here. Now I don't want to hear about any other VC that is not GIT. It was hard and counter intuitive (why should I stage first?, why do I need to pull, what on Earth is a PR and why do I need it)... but it became all clear. Audited and tracked differential changes.

Git seems hard because everyone wants to learn the process instead of the architecture. They want to remember the steps, because wrapping your head around the idea of a differential audit trail or the fact that your workdir is just a bunch of diff files merged together is not immediately intuitive

Emails are a good medium and no I will not back down from this opinion.

I don't understand why people made up this term "stacked diffs". Everything in git is a "stacked diff" in some sense, and branching off non-main branches is a core aspect of git. I feel like people really conflate git with github, where it's the PR that creates this proclviity towards "unstacked" diffs.

You really don't understand how Git can be confusing????? Wow. It's because there are many hidden gotchas for it (hidden abstractions, data stores), and the terminology used in Git is not intuitive for native English speakers. "git push"

In school we were required to use Mercurial, svn, tortoise, cvs, and git

I only use merge. Why use a wacky feature when merge does everything I need. Rebase doesn't confuse me because I don't use it.

I started with RCS for years till we migrated to CVS. Then was the migration to svn (with some MS/Rational proprietary stuff mixed in). Then Mercurial for a bit. Git is still “the new kid” - I think I really did not use it much till about 12yrs ago? It seems so odd to hear people say all they have ever used was git. 😂

when I transited from SVN to GIT, git was very confusing to me, I could not graps the difference between git add, git commit, git push, local and remote version of the branch.

Mercurial was made at the same time as git with the same goal. For use with the Linux kernel after they stopped using BitKeeper and they needed a replacement that fit what Torvalds was looking for. Obviously git won that contest and took off after that. So it shouldn't be a surprise that Mercurial is more obscure.

Git is easy but people don’t have a lot of life experience with directed graphs of hashed diffs.

Used git my whole career, then I moved to a massive tech company with thousands of employees and found out they used mercurial. Now they are moving (or trying to) to git and I am upset :( I like mercurial so much better then Git. It just feels easy, git feels nasty and complicated. When I go back to using Git I don't feel like I've escaped the horror, more like I'm returning to it :(

Two things I don't like about rebase: With conflicts and multiple commits on the changed file, you have to solve the conflict over and over again. You rewrite history which is why you have to force push on your feature branch. If someone else also worked on the same branch and does a pull nothing fits anymore and git proposes to merge. It the other dev then merges the changed and rebased history into his own local version it becomes fucked up.

PrimeTime is story time for software engineers.

This was interesting. I used to work for a company where the repo was in SVN, but it was very slow. Then - after a long consideration - it was migrated to HG, but they're now using GIT. BTW CVS != CSV. Also, why use a monorepo at all?

guys how can I get informed about what Prime is up to? like he mentioned he is going to be working on HTTP on September but how can I get notified about this?

i've used git since like 2011 and it wasn't til sometime earlier this year that I learned that there are 3 pieces to the puzzle: your local branch, the local repo that tracks remote, and remote repo. For a long time i'd be confused with the message 'my local branch is up to date with origin/', but that can't be true cause I knew someone just merged into remote. that message is really telling you that your local branch is up to date with the local repo, which tracks the remote repo. I got away with this for almost 15 yrs lol

Honestly the Git vs Hg thing is more nuanced than just "Git had Github" since Hg had Bitbucket which at the time was feature comparable (and Hg exclusive). Git had the kernel, but Hg had plenty of big names using it too like Mozilla. Early on (back when svn was as popular as git today) Hg had better user experience with a decent cross platform GUI tool, a more familiar CLI (for those switching from svn), and Bitbucket even let you have private repos for free which Github did not at the time. I believe part of the "git is hard" sentiment is parroting from those days since if my memory serves even git's supporters admitted that the CLI experience was a bit raw (i.e. cryptic messages). Over the years Hg's advantages would be chipped away, especially after Bitbucket added Git support and clearly favored it. As someone who supported Hg up until Atlassian dropped support I am kind of surprised Git managed to steamroll everything based on where it was. Obviously today things are very different, but I don't think we got here by any singular facet.

Git is not hard, but it goes in the way of devs instead of just working. People don’t want to spend hours learning version control, they want to actually code.

I'm with you that git is overall pretty good. However, there are definitely areas where it's not truly user friendly. In general, command line tools aren't too user friendly, since the --help command usually doesn't tell you "these are the most common things you are going to want to do and the syntax for those, but if you need something more advance, there are these commands and options, too:" and instead you need to spend a lot of mental processing cycles on figuring that out what are the 2-3 commands you are actually going to be using most and how to use them. Then there are common flows like rebasing where they actually require knowledge of --force flags, which come with drawbacks. If that is supposed to be a common flow, the drawbacks should have been mitigated earlier, but the --force-with-lease flag didn't exist until much later and the -f flag doesn't use that. There's also an even newer option called --force-if-includes, and from a first-time user perspective, this is a really confusing API. Naming-wise, the existence of branch and checkout commands (which the latter actually creates a branch, too) is not the best. That's why the switch command was added in newer versions of git, but you still have all of the old commands available, older tutorials are still going to tell you about older methods, and as a new user you're going to have to figure out how to filter through a lot of old information to really figure out how to use the tool. That's not to mention that merge conflicts are still, IMO, most easily handled via UI and IDEs. Resolving them in the cases where there was an overlap in development at all tends to not be easy and I find myself frequently having to edit by hand and then compile and retest the code. Even sometimes in cases where the changed lines were side-by-side and not truly changing the same code. It could for sure be a lot worse, but I feel like you basically can't easily learn to use git from git itself and have to rely on a lot of external tutorials and tooling to actually use it in a reasonable fashion.

Can someone explain why you'd have millions of files in a repo? What possible benefit could that have over splitting this Galactus-sized mono-repo up into smaller repos? Also why do you need to care to version track millions of files? I'm having a hard time imagining that this would be necessary but I'm curious and open to any answers. I do come from the embedded software world, so maybe this is a web dev thing. 🤷‍♀ For me, most files are only generated for a build and then no longer necessary afterwards, so the core repo is far fewer in size.

Stream chat reeks of Dunning Kruger and skill issue, but then again which twitch chat doesn't? Literally most of those arguments are "git sucks because it sucks", one person made a good comment about scalability at monstrously large codebases which isn't an issue for 99% of people and companies.

That hot take on GIT being easy and just needs a little learning time was spot on. Same thing here though where I get strange sync issues once in a while where rebasing is the solution. GIT is the best

Amazingly many people made false assumptions about the costs of stat of a million files - on local ssd this is very quick. When you try using a network drive or spinning disk or a compressed file system, things all slow down dramatically. Also caching with enough memory means local repos stat results get cached so RAM helps a lot. But fundamentally codebases need modularisation and project separation so they don’t grow too monolithic

About git and rebasing. I found that people that do not care about other people PRs and what is going in their own project are having trouble with resolving conflicts. Becasue sometimes you need it takes a bit more than just simple merging to files to resolve the conflict. And to do that, you need to know what was the intention of the change of that other person and what is your intention for change in the code.

I found myself having to teach coworkers git a lot, and I always begin with the directed acyclic graph thing. It's what made git click for me. When I perform git actions I actually visualize the nodes moving around.

I had to stop and think for a moment how the hell one guy wrote a version control system from scratch with no tutorial on how in 5 days. That is seriously incredible. I didn't know it was that quick.

15:20 what??? sic means "written as was said"

The post got bashed on reddit. Basically: - the issue was niche. While git people didn't just blindly did what they were asked and instead propose better way to manage the project, fb would just not listen. On the opposite side, Mercurial people did the "promise the world" thing to get the customet. - it is not all of facebook, just some teams - git is easy, it is not that "you get stuck", but people think it is strange that issue arise when you don't know how a tool work.

Wow. Git was a breath of fresh air compared to all prior source code management systems. Migrating off mercurial saved a lot of problems but mercurial itself was also an improvement on prior systems.

Just don't mono repo. It stops scaling eventually - doesn't matter if its Git, Mercurial or something else.. It's like vertical scaling hardware. You can do that for a while but it will stop to work eventually.

I would never consider taking any advice from facebook.

facebook "created" stacking patches as much as git "created" diffs, lol, they just popularized a long-known good idea... Darcs is way better for this kinda stuff, it was made in 2003, and it's still active (last release in may of 2024, as of now), and the entire point is "focus on changes rather than snapshots", where you work with changesets, not snapshot histories, you work with patches, not diffs, you can easily swap your patchsets around, or create another patch to fix a conflict, it's ideal for having a parallel workflow

I am a git master in intellij. I only use the cli to unblock my branch when intellij bricks my brach. Now I am no near a master on the git cli I can do basic things but I for sure can not resolve merge conflicts in the cli.

I'm shocked that Prime is so surprised at the idea of 14 million files being realistic. I work at Meta, we have *easily* more than 14 million files in the mobile repo alone.

git felt hard when I was learning it, but once I learned what all the commands where it immediately stopped being confusing. Git is not hard, its just a lot of commands to memorize for the new git user

I switch to master. Pull master. Switch again to feature. merge master into feature. Resolve conflicts if exists. push feauture. Then I open PR. rebase was not clear to me 😢 and I don't use it.

The git client is hard, not git. There's a reason that there are a million paid tools to interface with git. If you look at git docs there are several ways to do things and they all have several possible parameters, and their explanations tend to be very technical, creating situations where you open the docs with one question and leave with many more. I absolutely hate when I have to use git directly, even though I love that when I have to it does have everything I need to fix whatever problem I'm having. TLDR: I think git docs need a "basic" version, with the most common commands already with the most common parameters, followed by explanations that are way less technical than what it has right now, and an advanced version that throws the book at you - what it has right now. That's what paid git tools are offering, shortcuts to routine operations.

Git is not hard, the hard part is when people use it in a way that makes it difficult sometimes to work with

Git is maybe easier when coming from SVN because it makes you appreciate all the tooling Git provides that SVN didn't. Like doing a rebase in SVN is usually organization-specific and there is no proper way to do it. You could merge trunk into your branch, or recreate your branch from trunk and merge your feature, or attempt to recreate a Git rebase by merging commits one by one. Some people write scripts to do all this, otherwise what should be a simple rebase takes a ton of time in SVN. So then you start using Git and the rebase feature is a godsend, never mind not being forced to do remote-centric version control. Can't even imagine rebase being confusing unless you're doing something insanely complicated on a regular basis.

Hg is the same as git just with better branch management. And Prime, do you actually think a million file repo is rare? Companies that use perforce or clearcase are usually giant monorepos.

Mercurial is 10x more sane in terms of UX, DX and handling data than git. That's all to know ;)

Sic isn't for pointing out errors, it's for quoting verbatim and indicating that the error is a part of the original quote and wasn't introduced by the author

Dunking on Airbnb lint and style guides. Truth!

There are moments where you'll do git the way you're supposed to and it just decides not to work in the way it should. These are incredibly rare. But there are tons of moments where someone will say "oh I don't use merge, I use rebase" and I'm forced to recognize that git is legitimately hard for some people.

The amount of times our senior dev has to ask the other senior dev for help with git makes me feel way better about myself.

A colleague of mine somehow managed to void a commit or whatever. 2 branches and he decided to merge branch a to branch b and then b to branch a and pushed both. Somehow when he pushed both a commit on branch b that was not yet pulled disappeared. He could not explain what he did exactly and I don't think git allows a push before pull right? Also rebase before pr because I ain't doing your damn merge conflicts for you!

not only large-scale repos (in terms of the number of files) can be a problem, but also repos stored on remotely mounted file systems. the slowness is proportional to both the I/O latency and the number of I/O calls.

honestly stacked diffs seem pretty cool. i am big supporter of using text based solutions instead of binary blobs. can always use a filesystem that is text file optimized and has anti redundancy features like git has.

People beware of stacked PRs with squash merges, it will mess your codebase, you have to squash merge PR 1, then interactive rebase PR 2 to drop the commits that were squashed (of course you'll have to force push), after that you can merge any way you like, including squash merge PR 2 (unless you have a 3rd stacked PR, in such case you start over).

I think why a lot of new-ish developers aren't getting git 100%, is that a single dev, freelance or hobby oftentimes aren't cooperating with other people on larger projects, and typically only need to add, commit and push. A single dev working on something don't have to make a separate branch for a feature, they can work all they want on main where no merging is needed, and simply push it when it's done and testet locally. They simply aren't used to other people messing around in the code base, leading to conflicts *insert possum don't touch my garbage meme*

Oh cmon, I will be on Vocation on August 14th. Should I join while I am lying in the Beach with my mac?

git is hard = skill issues, so many people just dont want take 10 minutes to learn the basic commands and work flow

As a git user the biggest thing that makes it hard for me is the absence of Magit for Mercurial. The other smaller issue is that git felt at least from my pov simpler but more complex when going further.

Only issue I encountered is when changing a component name's case, like from "components" to "Components", git doesn't seem to track that.

Git is only hard for people who can't resolve merge conflicts. Here's a fun story involving merge conflicts that happened at my previous job: I was hired as a senior frontend dev (React) and we were staring some new projects I have created the frontend repo for the first project and setup the structure of the project, a readme file for instructions (since other devs were juniors and they never used react) and some basic CI/CD pipelines. The team leader comes from her vacation and the first thing she does is to ask the devops to downgrade my access to "developer" because "she is capable of maintaining the repos herself and will handle merge conflicts" (she's not my superior btw, just some weird corporate hierarchy). Comes first merge conflict, she couldn't do anything for 3 days and then asks the devops to make me a maintainer so that I could resolve the conflict :v

Git's not hard, most of the people who know git are just absolutely fucking terrible at explaining how it works to someone who doesn't know it at all.

Just a few: Pull/Fetch/Checkout/Clone all different things (Pull/Fetch should be same thing w option flag) "Checkout" means "switch branch" A "branch" is just a pointer to a commit "Pull request" is a push request A branch doesn't always point to the latest commit, and neither does HEAD!

I had a tortoise in my trunk.

Microsoft made a series of patches to git to make it monorepo friendly, you know, they are also a big monorepo user.

git isn't hard. but solving issues can be absolute hell. +1 pain if the person you're working with does not understand git, which is 60% of the time. +1 pain if there is a person going crazy with its advanced functions where i find my local behind remote in so many things.

I've never used diff stacking but it feels terrible. The whole idea is that you have small, manageable, easy to review diffs, but then, because they're all stacked, every single change has an impact on the changes above it. I can 100% see scenarios where small updates to a diff propagate and lead to consequences on a bunch of other diffs. Seems convoluted to me

Git is one of those things that makes a lot of sense once you understand it, but it's a lot to learn before you understand it and feel confident. My team has been with me for FOUR YEARS and they still don't quite understand how feature branches work. It's actually so simple, but somehow it still confuses them. And I understand because coming from TFS it was a lot of extra stuff to learn.

Microsoft switched windows source over to git and solved the massive file sizes and added support for partial downloads so that not every developer needed multiple GB of source. So yes GIT today can handle very very big code bases.

For a lone developer, git is overkill. What a lone developer needs, is just a file system that remembers previous versions of files. That's it. A lone developer doesn't want to commit and push and pull and branch and merge. We want to go directly to the part where we edit a file and save it.

I can swear to god I saw this video like a few months ago. Is this a re-upload?

“You can always upgrade, that’s not hard to do.” Tell that to my company, our internal development team took 2+ years to transition from svn to git. Everyone hates it too since it’s no longer integrated into our internal dev tools and we actually have to use the CLI now 😂

How do you do `hg cp` in git? It preserves blame in a way that looks like a move, but also preserves the original.

The only time I do rebase is when I start working on a branch and the main branch get updated so I rebase to have the latest changes, I still can't see any other situation to does it again, unless you are working on a branch alone even though I still do merge in that case too.

I have lots of coworkers struggling with git and I thought about why, ans my conclusion was, that they started off with a GUI tool which does multiple git commands in background per click, and they never really tried to learn git commands. An then those people tell freshers stuff like "never use rebase, it is weired and destroys everything" who will then also struggle. I started off the same way and I'd say, I'm not a shell only guy, but when it comes to git, I really enjoy using CLI instead of any GUI.

I'm a n00b. Git is hard to me because there's so much stuff. There are so many commands and flags. I only know the basics: commit, push, pull, checkout, branch, and merge. But there are so many other things that I don't know the point of. Like with the picture he drew to explain rebase, it looks to me like rebase is just checking out to another branch. I don't get it. Then there's reset that can mess things up, so I'm afraid to even use it. And I have no idea what head is about. I though head was just a pointer representing where you're at, but apparently you can be checked into a certain branch while head is on a different branch? I don't even know. I don't understand how Prime doesn't understand that Git is hard. He freaking has a whole course on it and is coming out with a second course on it, like what? If it's so easy and should only take 20 minutes to understand like he says, then why does he have two courses on it instead of a 20-minute RU-vid video?