Why Facebook Doesn't Use Git
ฝัง
- เผยแพร่เมื่อ 14 ต.ค. 2024
- Recorded live on twitch, GET IN
Article
graphite.dev/b...
By: Greg Foster | x.com/gregmfoster
My Stream
/ theprimeagen
Best Way To Support Me
Become a backend engineer. Its my favorite site
boot.dev/?prom...
This is also the best way to support me is to support yourself becoming a better backend engineer.
MY MAIN YT CHANNEL: Has well edited engineering videos
/ theprimeagen
Discord
/ discord
Have something for me to read or react to?: / theprimeagenreact
Kinesis Advantage 360: bit.ly/Prime-K...
Get production ready SQLite with Turso: turso.tech/dee...
Never heard about this react framework called git
All i know is react. LMAO
Tired of that command line nonsense? Just do version control in JavaScript😂
Bruh 🤣
Git gud!
GIT is hard for people who hold branches for months and then they're surprised that the merge conflicts will take weeks to untangle.
trunk based is now proven as a best practice
I push everyday before I leave it only makes sense
@@nehemiah6280 So what if you are pushing daily? Are you pushing into the main branch? The issue the OP talks about is you being slow and falling behind the trunk and unless you are pushing daily to trunk (which is retarded) there's no way your daily pushes make anything better. If anything it tells me you are one-man-show.
I push every friday at the end of the day to production
@@eleandres Even if you dont want to do that, its easy enough to rebase often as well. There are so many solutions.
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.
FWIW, let's just say that those estimates on repo size turned it to be *under* estimates.
The stacking stuff is unrelated to git vs hg, though. We used stacking for both. We actually have a wrapper around the source control stuff anyway, so many/most people didn't even notice when it switched.
thanks for the input, I love hearing insights from the inside too
I heard Google has their own source control would love to their reasons why as well
To be fair, with how source control software works i can't really think of anyway to make it scale well other than just merging really frequently
Errr putting ketchup on git aint gonna work.
Sauce?? If you worked as a coder on any level and still dont know the diff between Source and Sause i can see why you dont still work there
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 designed for OSS (specifically Linux kernel) work. It's fantastic at that, providing complex branch management, SSH key signoffs, and a ton of other stuff that allows it to float out in the public space. It's a shitty tool for corporate work.
Mercurial is way simpler, lightweight, easier to use, much more practical for corporate work, and handles merges more effectively. Also, no rebase & squash. Which is terrible and no one should do it. But everyone does it.
@@thewiirocks not a single company I've worked at has done squashes or prescribed rebases so idk what youre on about. Using git with merges is simple af
@@Tom-jy3in I see it all the time. I had a company I consulted at DEMAND PRs with Squash and Rebase after I repeatedly recommended Trunk based development. We ended up losing some code after the squash and rebase failed to understand that code had been moved around. It simply... deleted it.
@@Tom-jy3in I dread to read your commit history log and trying to find out exactly in which order did a change got into production. We had to force fast forward only rebases before merge to main otherwise the log chronology was absolutely unreadable and filled with garbage "merge commit" entries.
@@Tom-jy3inIn everything I’ve worked on you rebase your own local branch before merging to a shared branch.
I agree that I’ve never seen rebasing done in the way prime talks about as a replacement for merge (with the exception of an internship), but it’s more of a courtesy to clean your own commit history before sharing it.
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.
Git is easy, period. Until someone screws everything and then you need to do miracles to solve things like keys pushed, conflicts badly resolved, old code removing new, etc.
So you call in the people that took the time to learn what they’re doing.
Or, you could learn the tool that’s necessary for your job.
@@jkdmyrsif you want an army of Git experts that’s great but understand that comes at the cost of going deep on something else. Specialization was one of the most impactful innovations in human civilization.
@@enginerdy"git expert" is something you can become over a couple week-ends reading the manual pages and trying out a few commands. That's like saying "not every mechanic can be a spanner expert"
@@leeroyjenkins0 Agreed completely. Specially when the needed knowledge to avoid problems is knowing pretty much 4-6 commands, and doing what you're told. Some people don't even read documentation on the git branching strategies and how to work, for god's sake. Or even common sense, how are you gonna hardcode an OpenAI api key into the codebase and push it through git ???
"Reverse engineered the bitkeeper protocol"
He telneted to the bitkeeper port and typed "HELP".
It was more than that
@@thewhitefalcon8539 Read his writeup. It wasn't. Implementing it was more work, but reverse engineering the protocol was just telnet and 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.
There are 4 versions: remote branch, local branch, workspace and staged
@@halbesbyte"there are four lights!" - Captain Picard
Don't forget upstream, and potentially many remotes.
Also never forget that HEAD can become detached, and point to different version of your file too, which means then you actually have potentially unbounded versions of your file... Which is obviously one of the main points of Git.
None of this covers the different copies maintained on disk vs memory. So you can basically double everything there too.
Thank you for the corrections about the additional states. So, yes - there are even more states to be tracked per file than "meets the eye". And the worst thing, according to me, is that many people attempting to explain these things define the new states in terms of their own definition.
For instance, a person new to git is surprised about their edited file being different from the local checked-out version. "Oh, you mean the index!" crows the senior dev at them. Blank stare is returned. "If... if you say so," replies the recent hire.
öhio man said the following as a reply: no way this is annoying af why sare there so many diffrences between them
Git is brilliant in that they can take common version control terms and make them do something else.
Sounds like Unreal Engine
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.
Came here for the tech history, stayed for chat being flabbergasted by git
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.
Based.
I have a script that zips up the current directory and uploads it to my server under a unique name. Do you really need more?
@@youtubeenjoyer1743It's gonna fill up real fast. And team work?
@@youtubeenjoyer1743 Tell me you know nothing about version control without telling me you nothing about version control.
How do you bisect a bug?
How do you accept patches from others?
How do you revert a change?
How do you search the commit log?
How do you sign off on commits?
How do you guarantee that the source tree hasn't been compromised?
@@MichaelPohoreski Sorry, I’m not a web developer.
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.
That would be fun. Used to love reading his blog posts back in the day.
@@PassifloraCerulea Best rants in the business!
I wonder if their internal VCS is so tuned to their processes, that it would be impossible to make public
Or if they simply don't want to get into the space, business-wise
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.
Me too, disgruntledly had to learn git because "everyone" uses it now.
What's the point of this
Now Olivia Mackall.
@@M43782 Yikes
Git's initial release was a very basic version without most commands we use today (even the confusing ones) like "commit". How was the first release of mercurial?
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.
I thought I had watched the exact same video before but then remembered it was Theo’s video about the same article!
same
Whoow😅
Says something about react content doesn’t it?
Exactly the same for me lol
Its reupload?
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 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.
The arguments you could oppose are that:
- It's a good thing to have people learn. It gives them more power.
- There are modern alternative command like 'switch', 'restore' and so on that are much better named. Besides, the old ones make sens if you think about what they actually do on the repo storage.
I think that's part of the problem - we should be using our brain power on writing s/w to solve business problems ( which is our job) rather than have to learn a new flavour of the month tool.
Also - I agree - the naming sucks.
@@lotus160 I agree with that. Having a "tool of the month" is a non-sens and counter-productive. (Looking at you, web devs.)
Git, however, is much more than that. And it is very much worth every second spent mastering it.
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.
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…
The tooling is what makes it viable.
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.
Tech corporations making cringy nouns for their employees is so awful.
"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.
What really blows my mind is that most people don't take this same time to learn other VCS like hg, fossil or pijul and compare their experiences. Everyone just assumes git must be the best for everything, because everyone is using it.
This. Git's documentation is horrible, and the onboarding experience is horrible. "It's easy if you buy my class" is a horrible answer that we would rightfully call a scam in any other industry. Even when I know what Git flag I'm looking for, it's always faster to just search for the answer on Stack Overflow, than it is to try and find the answer in Git's docs. And I know what I'm looking for. If that's not a sign of a serious usability problem, I don't know what is. How are newbies even supposed to know what questions to ask if they don't know anything about the tool?
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
Wait, is it? I thought your workdir is just whatever tree your HEAD is pointing to, unpacked.
@@MustNotContainSpaces it is. HEAD is a reference to a commit, which is just a bunch of diffs bundled together with a parent. You follow the chain until it ends, and apply the diffs in reverse
@@shaunkeys7887 a git commit references it’s parent(s), but that's only metadata and is not used to process the content of your workdir.
If it were otherwise, you couldn’t do something like a sparse checkout.
This. Git has become far far less confusing to me since I started to try and understand what actually happens when you perform the commands. Remembering the set of steps to achieve X, then another set of steps to do Y is a poor way of learning such tools. When you understand how Git works it's impossible to fuck up your branch, and even if you do you'll always know how to fix it
Well, that's the point of a tool right? I want to use my hammer to hit a nail. I don't want to take a metallurgy class to learn about how the hammer's metal is composed nor a physics class to learn about all of the forces applied. I want my tool to do it's job in the way I expect it to which git is inarguably terrible at
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"
Yeah... he contradicts himself a bit here.
"I dont understand how people find git confusing..."
right after saying that he advertises his git course LOL
@@Braszx fr!!
"I don't understand how people find git confusing" comes from a place of too much ego on his part.
Even the response when he admits people do find it confusing is "Well you haven't taken the time to learn it"
He's portraying a picture that he has never found anything confusing and never struggled with discipline. Bro needs to have some understanding
It's not really a contradiction. He later agreed that it was the reason, and he said it was a stupid reason both before and after. Those two things can be true at once (It is the reason, and it's a stupid one).
I would be super interested in knowing more about this "stacking" approach vs "diffs" mentionned at the end of the video.
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
yea, i think the most confusing thing about git is it's English. Especially for non native speakers like me, a lot of words are similar and interchangeable but they have completely different meanings with respect to git. If they made up their own words or used verbose commands it would be great.
@@phoneywheeze in my case i would fully attribute it from just learning on the spot and not really learning those concepts at a base level - like even though I was confused by it, it always worked, so I never really felt like I needed to make sense of it. Not until recently, when I decided that I should have a better overall understanding of my dev tools
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.
In school we were required to use Mercurial, svn, tortoise, cvs, and git
Just got called out!
So sorry. I've only used mercurial, svn and git
It is good to learn all options. Same with other areas of study so you will know the tools you will use when hired.
lucky you learned source control in school
I am so confused by this. Tortoise is just a client, no? There are versions for different VCSs...
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.
git config --global rerere.enabled true
I've also occasionally had git bisect messed up because the commit that I was trying to find had been rebased.
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 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. 😂
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?
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.
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.
git is not hard the issue is it is built with language that makes it confusing to a new user.
luckily this language makes it very easy to Google though
hi, new user here, confusing language in Git has triggered whole panic attacks and I was using it for a small side project
the struggle is real lmao
@@4Bakers the first time is the hardest time, it'll eventually make sense and be awesome I promise! It will help to read the documentation too though, and watch videos/ask questions to more experienced devs too! :)
This is it imho. The concepts are simple once you grasp them, but when you’ve never seen git a fjcking “git commit”, “git checkout” or “git rebase” means nothing to you intuitively.
@@_alexlazar_I feel the same. Especially as a not native speaker a lot of the words refer to concepts that I would've no idea were being used for maintaining the repo.
PrimeTime is story time for software engineers.
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.
At least my experience has been that when using rebase you're going to be solving merge conflicts just like you would with a regular merge. Maybe you can find some more unusual cases where it gets more difficult but I've not come across those.
@@seneca983 And then suddenly, git rerere
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
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
Perforce here, and I've always much preferred its P4V GUI utility - would really like to see that re-adopted/factored for Git honestly. Aside from its Flow & Layout, its default Hotkeys just felt better/more natural e.g. select changed file and Ctrl+D for its Diff presented graphically, and even editable in it too.
I'm not familiar with P4V GUI, but there are tons of different GUI interfaces for Git besides the official one, maybe you'd be interested in giving them a try
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 always though of pull request as you asking someone with write access to pull your branch as you don't have write access so you can't push.
"Pull request is a push request" I've always found that strange, the wording is backwards
No, just no. "Checkout" checks out any reference. That it works on branches is just natural, but if it is confusing you just switch branches with "git switch". A branch is a pointer to a commit, true. But each commit hold info on it's parents, so there you have your "real" branch. And a PullRequest in OpenSource is actually really a pull request, because somebody with write access needs to "Pull your changes". If you work in a company with the "protected trunk/main/develop branch" method, then you could also just call it "merge" request, that's fine.
And the last sentence just underlines, that you too didn't take the afforementioned 2 hours to learn what git is... complaining that HEAD does not point to the "latest commit" (whatever that is) is just mindblowing to me :D
PS: Forgot your first point as it's crazy :D not going into pull vs fetch ... That I leave to the web based trainings you should've taken at your work :D
No, they shouldn't be the same thing...
@@microcolonel Why not? _pull -m_ for merge
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.
Back when we used svn we had a monorepo for all stuff in the company (small company though). As svn allows you to checkout subtrees it was no problem, each project had it's own tree. But it made it incredibly easy to use parts of code from another project, as it was the same repo you could svn copy it. Monorepos have their advantages. We never had performance and scaling issues as well, but yes, we aren't exactly Google.
@@Mnementh-ub8mdthe only ones having issues with monorepos is git-heads. so their solution is to announce monorepos an anti-pattern, unscalable and other fud.
It might not if you're a small company.
Pijul handles most operations fine at scale, just not record (what most ones call commit) because it still has to check every file for changes.
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).
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.
Well, this is going to happen in any project regardless of version control. This is more a question of collaboration than a technical question.
Yep these arent git problems but not being a prodessional dev problem
@@jhoughjr1 true, but still I found people complaing about git then, and how hard ebasing is...
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.
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.
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.
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.
Who spend hours learning git?
This stupid logic could be applied to any tool. But it’s stupid
@@vilian9185 bro just launched entire course on git, and you still doubt that.
@@paul_w I agree on this one. With a power tool e. g. I know what its used for. And I really do need a drill. With git its always kinda the same "everybody uses it, so you must too"
Weird take. Most things in our industry is hard and you need to learn them because they are essential to programming.
The build system, the version control, ci pipelines, test frameworks, containers, config files etc. There are a million things that we need to know you will never get to the place where you can just write some logic and be done for the day.
We write in c++ and I always tell people the easiest part of our job is writing in c++. It is everything surrounding it that is difficult because it is there you can have actual errors and slowdown in productivity.
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 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.
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.
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.
that's not an SCM problem tho
@@kyjo72682 it is, in a way. if there is a significant number of I/O calls (such as stat) that the program has to make to complete an operation, then it will feel slow if the file system has high latency. the lower the number of i/o calls, the better.
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.
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.
15:20 what??? sic means "written as was said"
Totally! My modern equivalent to explain it would be „something something (seriously!)”
But practically it's almost exclusively used in cases of quoting text with an error in it to note that the error was in the original and not added later. In this case, the grammar seems to be slightly off.
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
Wow so her masters in conflict resolution wasn’t applicable ?
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.
Thank you Prime for voicing the "Git is easy. Just spend the minimal effort to learn its basics and you won't be confused"
I'm known as the git expert at my company. I think most of my peers just learn the basic commands and google their way out. Which is how we do most of coding. However, all I did was watch a few videos on Git and practiced and instead of relying on commands they told me to run, I applied the knowledge I knew to do what I felt made sense.
I don't want to say it's easy but I certainly think every programmer can solve most issues if they put that extra effort in.
I'm the resident "git expert" at my work. Everyone uses Source Tree to do their work. Meanwhile I do my git stuff off the command line. Whenever they have an issue, I make them pop open the terminal, and teach them the commands.
Some of them still refuse to just adopt CLI. Many of the reasons I'm good with Git and fix almost any problem is because I use the CLI. Don't know a command? 'git [command] --help' is all you need to put in to get the docs.
Afterwords it is a matter of just picking a diff tool and binding it. You can do a few more other customizations like shortcuts but I barely use them. Tab completion is good enough and my processes are just commit and add files with occasional pull for updates.
@@ChrisCarlos64 The CLI feels better for many things but trying to do things like line staging in the CLI is comparatively kinda painful. Also exploring the history is much better with an actual graphical visualization of the commit graph.
I've been using it for over 10 years, read man pages many times, and I still think it's confusing.
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.
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
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.
Spot on reasoning.
I think a really common problem is that in many projects, less technical people are required to learn git to be able to contribute. These people might not be used to commandline tools, version control systems other than "everything is in sync" style systems like Google Drive or Figma. All they want is to be in sync, and git seems like a really complicated way to achieve it from their perspective.
Thats just part if rhe job and if you can pass that low bar maybe you dont need to contribute.
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.
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.
Emails are a good medium and no I will not back down from this opinion.
Somebody should do something about the major providers blocking small fish and self-hosters
git's a specialist's toolkit with a decent manual, only the manual was written by specialists so it accidentally presupposes some feldspar knowledge. It's somewhat easy to pull out a spanner when were looking for a hammer. Also, the label reading "force multiplier" might make you think this is the closest thing in there to what you wanted, so you don't bother to look for the actual hammer. And then the spanner turns out to be a poor hammer substitute!
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.
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?
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.
Google last time I checked is still using an enormous monorepo. Which they insist is more efficient, but I frankly think it's cope. I'm sure with the tooling it's about equal, but I think they could've easily converted to git and been fine had they done it early enough.
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.
@@albanx1 Sadly the git manual does a poor job of explaining there are FIVE different places a git command can interact with:
* stash (local)
* workspace (local)
* index (local)
* local repository
* remote repository
Lol.
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 :(
To be clear, I use git all the time and know it well including console commands etc. It doesn't mean I like it
yeah dude same. bitbucket killing hg support was brutal :(
I was using mercurial and bazaar before moving to git and it was really a bliss to start get responses from any version control commands in few hundred milliseconds (using git) instead of few seconds on python based version controls. Maybe those people who cared about it in facebook just kept using git for their work and used adapter to push their code finally to mercurial when it was really necessary to push to remote 🤷♂
Git is much easier to blow up your local branches compared to SVN or Mercurial. I have spent easily 10x as long using SVN and Mercurial at companies I've worked for compared to Git, but somehow I've only run into a issues with merges deleting old code or branches needing to be deleted and redownloaded on Git. It may very well be that Git is easier to use as a power user, but if you're the 99% of cases where you just want to make a branch, write some code, and commit it it seems much more error-prone.
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.
As far as I remember git was used because people wanted to use github, while bitbucket was more of a 'github of hg' thing. So bitbucket was only used by hg users that looked for a similar experience. The reason is probably, that early on popular OSS project were on github. Something I didn't understood (and still don't), as we just came from the aftermath of the Sourceforge disaster and I didn't want to rely on a third party again.
Git is confusing to the extent of the power it gives you. The complexity is in learning its fundamental model like the chatter said, once you realize that it is actually straightforward and it allows you to perform fairly complex operations if you want.
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.
Since I learned how to rebase I almost never merge. And man was that a change for the better.
It can be worse. I know people who proudly exclaim "I squash to keep my history clean" - sure mate, a room that doesn't exist cannot be dirty. Ever tried to bisect though? You'll wish that history still existed.
@@henningerhenningstone691squashing absolutely can keep it clean, if done right at least. If I commit unfinished code, I'd rather get to a single commit for the full feature that went into a release than to piece together 5 different commits which include unfinished code. this falls apart if you start squashing stuff which was actually potentially helpful to keep though.
@@kneesnap1041 If your feature is extremely small then yes, that can make sense. But in that case you're unlikely to end up with 5 unfinished commits in the first place, and few features are actually this small. I would argue that so long as the code compiles at all (and for huge refactors even if it doesn't), retaining "unfinished" commits of a feature can be valuable to aid in fault-finding later on. Your "single commit for the complete feature" is provided by the merge commit on master either way.
Anything is hard for the ignorant
IMO the problem is that the user can easily do something that most likely shouldn't do. Git could provide a small warning if something "not noob friendly" is going to happen.
I have seen many people fed up with git, not able to escape from the issues they produced, and just doing git clone to a new folder, applying changes, commit and push again...
I use command line tools frequently, but git is the only one that to use it properly I often need to search google how to do what I need to do. And if I do a small mistake fixing it needs always more time that I would like to spend. Call it skill issue, but for me is just too error prone for small teams/personal use. I'm pretty sure that most not expert people are falling in the same issues, easily avoidable with some warning like: "are you sure to continue? It seems that you haven't (fetch/pull/whatever) .... "
the big problem with git is reverting changes.
I, for example use git through the terminal and sometimes when you add a folder some temp or unnecessary files get added. so you need to find them and remove them from the 'add' state before the commit (it's pretty boring and makes you question you life decisions, like every manual command).
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.
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*
Git added a file system monitor that you can turn on, which fixed the git stating many files.
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.
There’s so many hard things to do in Git besides rebase:
- revert a revert
- cherry pick with conflicts
- switch two branches history
- removing commited secrets
Reverting a revert is easy. Cherry picking with conflicts suck yes, but there's tools out there to help. Also keeping your commits concise helps ease this pain.
Removing secrets, well that's a pain. Someone committed it and pushed it to the remote, now every one has it. Best remedy is don't do that. I'm sure committing it to Mercurial is also frowned upon.
@@warmwaffles Reverting a revert is easy when you can do it right away. But if there are changes after the first revert git history could be messed up. Sure ideally none of it happens but it doesn’t work that way.
@@warmwaffles agree on consise commits
Did the build your own git code crafters challenge and it cleared so much basics for me, now i dont feel confused with complicated git concepts either
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
I had a tortoise in my trunk.
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"
Dunking on Airbnb lint and style guides. Truth!
When I started Programming, Git was confusing as hell. It took me multiple years to fully understand that basics, the basics that is.
I have destroyed multiple of my git repositories, did not know how to recover them and so on.
Chat GPT helped me a lot with understanding GIT. The concepts are just quite abstract and you will NOT be able to properly use GIt without consulting the Documentation, which I do consider non-userfriendly. Userfriendly is, when I can use something WITHOUT consulting the manually each single time. Just one example: Rebase onto master - I couldnt tell you what it does, without peeking the docs as of right now.
and by the way. 7:42. I did NOT get you explanation of rebase there.
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.
I've used rc, cv, some Microsoft tool which no longer exists, svn, Perforce and git. I don't like any of them, but git seems ok compared to the others. For single developers svn is probably fine.
Edit: the MS tool was Visual Source Safe.
FB didn't pass on Perforce because of any technical flaw. It was just a bit old then and not forward looking like they wanted. (I was on the initial team that visited FB)
“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 😂
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.
have all developers always have access to all existing code. To learn and follow similar practices
@@aqua_pi Thanks for replying! I see some of what you mean, but...
Hmm... Well, in my company, a group of developers are given access to all repositories in a give GitHub organization. So you can still have access to repositories split up.
And following similar practices comes from 1) clearly documenting coding standards and expectations somewhere, 2) ensuring code standards are maintained already, regardless of where you look; 3) having project seniors enforce those on PRs and other code reviews; and 4) good organizational training/education.
@TenFrenchMathematiciansInACoatwhat? no. fb main repo has everything from data infra services to network switch custom firmware. the size primogen found laughably unrealistic turned out to be underestimated fairly soon. it’s not hard to get to this size once you do your own custom everything from compilers to kernel, and there are serious benefits when working collaboratively and the core / products have certain dependencies.
Look up advantages of monorepos
I think people got confused on how to use git when people started throwing around the term 'gitflow'.
I actually love solving merge conflicts
I think the big confusion for people on git are explanations that are bad and start further down the path that the person needs. If someone knows another vcs, I would equate rebase to get latest on Main to make sure your changes still work.
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