Why Facebook Doesn't Use Git
Vložit
- čas přidán 6. 09. 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
Just npm install it
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.
Came here for the tech history, stayed for chat being flabbergasted by git
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
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.
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 brilliant in that they can take common version control terms and make them do something else.
Sounds like Unreal Engine
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
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.
I would be super interested in knowing more about this "stacking" approach vs "diffs" mentionned at the end of the video.
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.
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).
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..
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.
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?
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.
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.
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).
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...
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…
"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?
Tech corporations making cringy nouns for their employees is so awful.
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.
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.
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. 😂
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
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.
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
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.
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.
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.
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.
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
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
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 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**
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 had a tortoise in my trunk.
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.
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?
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 easy but people don’t have a lot of life experience with directed graphs of hashed diffs.
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.
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
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.
16:50 "How can I do A?" "You should do B instead." where A is actually absurd
"yeah but i can't do B or really anything from C to Z, I really need to know how to do A" you can't always assume people just want to do something regardless of the way they get to do it
With the benefit of hindsight A (monorepos) turned out to be the correct thing to do and want.
[sic] - The author calls out a quote's spelling or grammatical errors in the original text.
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
"Metamates" must have come from upper management
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
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.
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.
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.
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.
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.
Git forces you to conform to its way of thinking about source control. I’m fairly familiar with it and can use it for its normal use-cases (including fixing conflicts with interactive rebase or reset), but it forces me to think in the format of distinct linear paths of discrete line-based diffs and single-point combination.
If you’re using Git, you don’t track distinct progression-graphs for different files or code-sections, you can’t efficiently use it as an “undo tree” in a coding sessions, it’s difficult to use it for programs/prose/other-files that don’t pervasively use line-based semantic boundaries, the process for changing existing branch histories is *very* tedious (especially if you want to manipulate multiple interconnected branches), plus the efficiency issues brought up in the post.
And the above is using a git porcelain (Magit) and only dropping into CLI when it goes into a bad state. When purely using the CLI even normal operations like merge conflict resolution are annoying to deal with!
Git is predominant because it was simpler than the standard for VC *at the time* and had a first-mover advantage. That makes it an improvement; it doesn’t make it *good*.
(Though I can’t say Mercurial is necessarily better, not having used it.)
The thing of people not spending 2h and thus not learning the basics is real af
Git added a file system monitor that you can turn on, which fixed the git stating many files.
8:05
Don't forget about it !
Only issue I encountered is when changing a component name's case, like from "components" to "Components", git doesn't seem to track that.
Chat saying that git is hard confirms nobody on twitch/youtube is an actual developer
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.
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.
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
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 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 🤷♂
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.
That's not how TLDRs' work!
Simple question: are you too stupid to use git? It’s so simple and well defined that if the answer is yes, you’re probably incapable of doing your job either. Skill issue. A huge one. Like all those “I only use gui” pussy “programmers”
A btw if you need a paid tool to create a shortcut for yourself… i mean… pathetic
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.
11 Minutes in, and you are still not talking about why Facebook is using Mercurial.
Its so tiring.
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.
“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 😂
I've survived rcs, cvs, mks, svn, vss and yes hg - loved it - only switched to git when Atlassian abandoned hg
git is hard = skill issues, so many people just dont want take 10 minutes to learn the basic commands and work flow
10 minutes? lmao
@@elzabethtatcher9570 you can literally watch 10 min youtube video that covers basic git work flow that will cover you for 90% of use cases
10 minutes is dishonest
@@jboss1073 10 minutes - you can find bunch of youtube videos that show basic git workflow and commands in that time format, this will cover most use cases to get anyone started...
I think people got confused on how to use git when people started throwing around the term 'gitflow'.
I actually love solving merge conflicts
How do you do `hg cp` in git? It preserves blame in a way that looks like a move, but also preserves the original.
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.
As an artist Git never made since to me when ever the programmers for my games in school ever talked about it
They could do what Google does for AOSP - use the repo tool to manage over 1000 repositories.
That's worse
Git is one of those things that looks extremely difficult at first (kind of like vim) but once you use it again and again and again, it gets so natural to use
I don't need one year to understand git
@@vilian9185 meh probably like a week of everyday use
git isn't as hard as vim
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
Git is easy until you mess up or something goes wrong
Coming from a TFS UI only world, Git can be hard.
That file checkout and it comes back issue happens when you have a file named something like AAA.json and aaa.json committed into the repo from a computer with a case sensitive filesystem and then you try and handle those files in git on a case insensitive filesystem like on a Mac.
I don’t rebase, rewriting history is the only way git can get into a really confusing state
"Theirs" and "ours" are confusing
more people should learn about stuff like DARCS that do MASSIVELY different approach to version control than git
6:00 I would have said submodules, specifically the nuance of how `git checkout` does and what it might to do the stash in a submodule repo - that can be quite a shock. That said, that isn't really something "hard about git" but instead about a specific feature of git.
Microsoft made a series of patches to git to make it monorepo friendly, you know, they are also a big monorepo user.
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.
16-way double octopus fatality merge hypothetical
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.
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.
as a hobbyist coder its so weird hearing my company's name in a video not knowing they have a solution like git