Didn't really make a very strong case against Git. "It's not as good as the non-existent alternatives" and "companies make too many repositories" are pretty weak arguments.
I think the problem with Git itself is enforces a lot of stuff (to my understanding of it) of how to work with the repo. One of the thing that I could think of: The design itself comes with the idea you should clone the whole state of the version control to your machine instead of working through a lightweight API. This enforces you to download infinite-size of repo code (or even subdirectory using git sparsecheck out) instead of the solution at google which is requesting on demand i.e. NFS like iCloud drive/Google drive/Dropbox drive. On such solution, you could scale your repo size horizontally. Hence to this limitation, it would enforce you to create a separate repo to deal such issue. The problem with having too many repositories are (again to my understanding), the lack of maintenance or update on repos that are not as often to be looked at but still requires it to keep running/alive
@@willysoesanto2046 you can specify a depth when cloning. However, the git man page is headed with "git - the stupid content tracker", so it is admittedly not super advanced -- it does its one thing using POSIX tools, and it does it quite well considering the price tag.
the real problem with git is that it’s wildly unintuitive, but no one knows how to make something that’s more intuitive without losing power and flexibility. I have to wonder what system Apple uses
The problem I have with this take is that he defends it with a circular argument. "Git is bad because it doesn't scale. Git doesn't scale because it forces large companies to host hundreds of thousands of repos. Hundreds of thousands of repos is bad because it doesn't scale well." The issue here is that he failed to make the case why 100k repos is a bad thing. Nor does he make the case for why this problem is something that should he solved by the VCS directly. By contrast, the fact that you can scale your code base to host 100k+ repos seems to suggest that git scales just fine.
Out of curiosity, I went ahead and cloned down the entire torvalds/linux repo, with the FULL history of the Linux Kernel. Optimally, you should just shallow clone a repo that large, but I went ahead and cloned the whole thing to see how bad it really was. It took about ~2 minutes to clone down all 5GB of the repo. Some of the git commands actually took a second or two instead of being instant, but I think that might have just been my terminal emulator printing text slowly. Usually I'm not working with a git repo with that many files. It didn't checkout properly on Windows, so all the files were "modified", which probably contributed to some of the slowdown. Still, for being on the wrong platform, and intentionally pulling the largest repo I know about, and using the wrong git commands, it still worked pretty well. I was able to get the oldest commits in the repo at 2005. Which is pretty dang impressive, that I can go inspect the contents of a commit that's older than some people in this comment section. I'm still not seeing the performance issues with git.
Background: At Google for 7 years. Assuming that Git scales, you did get some stuff from having a single repo. Some things I can think of: 1. Tree structure (directories in a monorepo) are more intuitive than a flat list (lots of repos). 2. Easier to make changes that affect multiple repos/projects. Can be done in a single atomic change. Makes a lot of sense for shared components like proto/graphql/... schemas. 3. Can run E2E integration tests. Make a backend change that breaks the frontend? Should be caught with the frontend's testing. Especially useful if that component/backend is used by many other components. 4. Makes it easier to debug issues with upstream. I've had scenarios where it has been useful to edit a dependency for fixing my own code, the dependency's code, or performance. In multiple Git repos, there is a barrier to entry to tweaking a dependency, but in a true monorepo, you can debug almost any part of the stack.
@@alexlowe2054 Are you sure you got the ***FULL*** history? You sure there is not a branch out there somewhere that has not yet made it to the repo you took?
“GitHub is a monopoly” Don’t talk about Monopoly, guy who used to work at Google… Also Git is open source, GitHub is a company. Don’t conflate the two and then get mad.
@@carlosmspk Right. He's saying Git is crap because X, completely missing the point that his X is a special case. To spell it out: Git may be crap for X, but that doesn't support his general statements. Git is _fine_ for many cases. If not, more peopple would search for and adopt/build an alternative. Or monetize what they've already built internally.
"All the companies that we work with that use git have 100,000 Git repos" I don't think the case was ever made about how that stated problem is Git's fault? I don't get what's the through line in that argument, or how other tools could prevent this problems which seems to be a management issue, not a tooling issue.
I think the reasoning there is that git simply can't support that many files under a single repo. But he also failed to explain why 100k repos is bad in the first place. Modularizing code has always been ostensibly a good thing, so why should we treat version control differently?
There is a repository for every copy of the code out there. Many programmers are doing more than one thing ( bug fixes/adding new features ) at a time. So they may want to have multiple copies of the code. Google has many, many programmers doing many, many things.
One thing that always bugged me about Piper (and maybe this has changed since I left) was that I couldn't create a stack of changes for review (as you can with something like stgit), it serialized the review of CLs in a way that was really stifling. Steve Yegge is correct that when you arrive at Google and see all the stuff, you are kind of like, "Holy shit, the rest of the world is banging two rocks together compared to this!"
@@taku6157 I heard him gush about their internal source code indexer and other IDE functionality, which is clearly _not_ what git is about, so I'm very confused about his complaints.
No, google also uses git (e.g. chromium repo), but with massively huge monorepos (many GiBs), that makes git very slow (e.g. checkout - an hour, git status - minutes). This is manageable with advanced git features (sparse and partial checkout) and finetuning, but it takes time to set up. It's inefficient thus not scaling. It's a pain to work on those codebases even at google. They lessen the pain by using expensive SSDs, CPU and lots of RAM: throwing metal at the problem. But he's not talking about that. He's talking about code analytics, traversing (cross-referencing), and a build pipeline that catches errors and has the tools to dig into it quickly and effectively. Writing code is not efficient. Verifying and debugging the code is.
So the main argument is that Git offers difficulties with massively scaling up. Here's a thought: What if I work at a small company that doesn't need "planet scale"? Am I permitted to be happy with a tool that (almost) perfectly suits our needs? Sure, companies that actually have those kind of problems should maybe use a different tool that better suits their needs. That's what competent engineers do after all - carefully selecting the right(-sized) tool for the job. But my bet is that such a hyper-scalable tool, whatever it may be, would probably do WORSE at scaling DOWN.
I want to see a demo! I love industry folks with this kind of insight. I've never had a problem with Git, so it's never occurred to me how the tooling could be improved, and it sounds interesting.
You should have seen how terrible I was with mainstream tools after I left my contracting job at Google. I felt like a beginner having to learn how to use subpar version control tools, testing libraries and IDEs
well the diffing is made with standard unix diff, and is just on text, there is not awareness of the language, sometimes the diffs are just too stupid.
Actually git need to stick closed only for linux kernel purpose, u really don't need it on daily basis, u use it because of agile crap, which still don't know why u are using it, or git, or react and every other crap. Git submodules sound cool but is crap, I'm using every other tool available for greenfield project, not just git.
I know the journey along Google's historical support for their own products is littered with corpses. But if this is widely acknowledged as a Github killer, why don't they launch it as a rival offering themselves? You're leaving money on the table guys.
The only problem I am confronted to, while using GIT is instead diff. diff compare text files as plain text files, without knowledge on languages and their syntaxes, and it's the main problem every GIT user will encounter on day-to-day use except if alone.
Easiest argument against git is that it’s basically unusable on any large project without github and that allowed OpenAI to have a huge learning codebase for AI to automate jobs away.
No, that's not an argument. Gitlab and other front-ends for git exists, and it allows keeping the codebase internal while still removing a lot of the pain that using plain git would involve. Every company that I've worked for so far, in the last 10 years, has managed to keep its code on its own servers, without needing to resort to uploading to a third party like Github.
The scaling part is problematic, but the real issue with Git is that the commands so complex they're tough to learn, it's effectively like learning a new programming language, similar difficulty curve for most devs. AI makes Git bearable.
Wait?! people overusing a product is a fault of the product?! Steve might be a great software dev, but this sounds like he had a bad day on a project, and ranted it all the way to this episode. This rant makes him look like Grandpa Simpson... Or is he jealous because he didn't create git? Being overused seems like a good problem to have/solve...
Also, all the neat features on top of git like indexing can be done thanks to git hooks. I feel like he doesn't really understand how distributed systems can systematically evolve.
Git is good because it distributes control to the coder/programmer/engineer (Yay me!). Git is bad because of exactly the same problem (Hiss management !). And yes, the cli (command line interface) is a bit vi/vim/ed/unix. And yes, sometimes you need a wui (s/windows/graphics user interface) to see what's going on. If only we nailed our other foot to the floor we could stop going around in circles. Who is version control actually for?
Thanks for the insight and skepticism of Git. I have long felt we could do better, in particular why does Git cause so much grief? Using git is like writing code in assembler. It is so low level, so easy to screw things up for yourself and/or your team. Why can't someone come up with something safer and more productive to just do the basics? Why can't we have a high-level source control system the minimizes cognitive load, and maximizes safety and mental health? Yes, Git made some huge improvements, but has rested on its laurels for too long.
@@EricKolotyluk And regular weeby developers don't know to write few git commands, really u don't need it, even u build 100+ microservices, it's just hype.
i don't understand the hate comments? Git is very a old technology ,people just become used to git existing problem and its still isn't going to change anytime soon.
First exposure to Yegge and I gotta say I'm not impressed. A bajillion repos is an organizational issue. Monopolies are a systemic issue, meaning in another universe, Github would still be what it is, just built on Mercurial. The fact that some company has proprietary internal tooling that's great is basically meaningless for most SWEs, who incidentally are not working on world scale code. And honestly to say that 'developers love Github too much' and then being so lukewarm on an Atlassian product is hilarious.
LOL you're saying Git is bad because Google used it in a way that's not ideal which didn't allow them to scale well. Oooooooooookay... well use it right then?!
U are using microservies on daily basis because scaling, but microservices really don't scale well. U are using git because someone told u, but u never ever experience scaling issues, which he says. So that's why in 2024, we talking about hyped git, hype jira, hyped react and everything it's just hype, but nothing scales, even damn blockchains.
@@MrEnsiferum77 exuse me, what are you saying? Git is used in multiple companies because it allows you to collaborate on code within one or more huge codebasis in a single repository. This is not about scaling microservices either. This is about the claim that was made in the video about how Git doesn't scale well across huge codebasis. Nothing about hype whatsoever.
@@cheebadigga4092 still can't scale and can't rebase 100+ merge conflict files on it's own with ease. and i'm talking all modern tooling and technology today can't scale, it's just hype.
100000 repos? Which companies do have so many repos? I mean seriously, which companies? OK, even if I assume that some companies have 100000 repos, how exactly is that git's fault? And what alternatives do you have to manage 100000 repos? Seriously! this guy is intellectually dishonest.
Doing some back of the envelope calculations, we probably have roughly 100k repos where I work, but while not FAANG scale, it is a 30k employees software company with tons of products, not exactly your small startup either. And that was counting it fairly generously, including forks and a lot of dead repositories containing things like one-off migration scripts used ten years ago. I also never deeply felt this was an actual issue, at most it's just a symptom of the organizational issues experienced by most companies of that size.
@@kakwa Thanks for also mentioning that the counting is done generously. Still did you count it, or just a wild guess? Anyway, my point is that even if a company has thousands of repos, it does not mean that programmers work on all or most of them. Even a big companies like Amazon/Google, the engineers work on a couple of dozens of repos only, not thousands. Even then these dozens of repos are grouped differently based on the tasks they accomplish. Number of repos usually do not matter. The size of a repo matters and I do not think there is a better tool than git to handle big repo size.
I don't think Git is bad technology per se but the UI is poor. And I don't mean just the command line tools but the way the workflow and the terminology is built around its internal data model. When humans create stuff they don't think in terms of directed acyclic graphs and they can't be expected to know what "detached head" means. They want to make their work public and they want to undo the changes if necessary. Another disadvantage of Git is the cost. Nearly every company has to employ a Git specialist who knows how to clean up the mess which is quite easy to create by the way. Too much wasted time and energy just for the sake of version control.
This honestly tells me more about the general quality of engineers and not the tool. If you have a woodworking shop and need "specialists" to operate and clean the lathe, it means you hired mediocre woodworkers. You don't throw out the lathe! If your software engineers create bazillion repositories and can't figure out basic git terminology, you hired mediocre coders with substandard computer science knowledge.
@@Lttlemoi Or maybe instead of spending time an engineer can figuring out the latest features of C++ ( rolling eyes ), or scriping gdb with python, or ... . Which one do you think a manger would rather have their SE's do?
Linus is the best software engineer ever. If he writes a tool, it's one of the best tool ever, period. Now if you come up with a better tool after 30 years, it doesn't mean that git is bad, it's just evolution. Git was meant to be better than the CVS at that time and it sure was, they weren't in the same league. And now someone on youtube is criticizing linus without showing an alternative. Want something better than git? Code it yourself, after all you say you're better than Linus.
No it's not, it's just hype over git, best developers were way before, just plain c and assembly and fly me to the moon. Linus was the crying about merging conflicts, and he only brings merging conflicts with git on daily basis, because of weeby developers.
@@MrEnsiferum77 you're disrespecting him and dismissing git like it's not that important. The issue is git is one of the most important projects ever, and Linux is definitely the most important sodtea ever, guess who wrote that, And Linus made over $150m and NASA uses git and Linux. I'm sure there are better devs than Linux like Terry and RMS, but they're both poor and teery died homeless. Linus is a winner at everything, the others are just nerds who can't get a wife and can't take care of themselves or their family. you see, the code you write is meaningless, we might be the last generation to write code anyway, what matters is leaving behind a software that people use. 99.999% of the Linux and Windows and Mac and git users haven't sver seen the code behind it and it never matters That includes you, you haven't seen the code for the moon project maybe it's shitty. and the moon project itself while it's super cool, it's not useful at all, that's why we haven't repeated it. it was just a pissing contest with the soviets
@@elieobeid77 See the problem is, u are saying we are last generation we write code... No can stop me from writing code to fly on the moon. People went to the moon with assembly code, while Linus that disrespect svn/scm centralized solutions becuse he can't merge his own code he wrote. Doom game was merged without git , svn or other solutions, but just merging HDD's, yes HDD's and they have perfect 0 day production, that u can't do it with git. If something is overreused doesn't mean is great. React was used for Edge, also NASA, does that mean anything? React is overused and it's crap, but still weeby kids using it on daily basis, when scalability hits, it's the developers fault, not the tooling we using. When me and u will surprass scalability issues git have, we can talk is great, other than that, git rebase and git commit on daily basis, doesn't mean u need to use it. And the comments about nerds and homeless they dies, there are developers as any other, maybe they are not liberals at nature, so they don't give a f**k about modern tooling and systems. U believe that hyped AI is the future, but still u need that nerd kernel developers (that will die homeless and can't find girlfriend) that write code for that crap Linus, even hardly u can't find kernel developers that like to write linux code, AI can't do that, so the future of git and linux is not that bright.
@@MrEnsiferum77 I wrote a long reply and the OP of this video deleted my reply to make you seem correct, that's bullshit, I'm not going to rewite my comment, you go agree with the video poster and clap for yourselves
@@elieobeid77 Bro talking facts, he is not working on liberal web apps crap, u just falling of the chair that someone build tool for his own problems, and because you are using it u introducing yourself new problems. U will never ever lose time to rebase 100+ files at deadline, because git can't help u.
I'm genuinely curious what do you mean under "make commits algebraically operable". Mind you give some details to somebody with pretty basic math knowledge?
So what exactly is your problem with git? "it doesn't scale", sure, but you don't explain what that means. How does a source code indexer in an IDE have anything to do with git? Git just does the versioning. That's the purpose of the tool, that's what it does and nothing else. You know what really doesn't scale? Always synchronizing everything behind someone's back! The directed acyclic graph model is fantastic for scaling large codebases.
Well then if he just would have said Github is bad for scale he might have a point. But Git is written in C and there are many types of tools and UIs based on Git
mercurial is far superior, really u don't need git, i've been so much more in git s**t , than help me... jus try to rebase 100+ files and git show how dead is
Didn't really make a very strong case against Git. "It's not as good as the non-existent alternatives" and "companies make too many repositories" are pretty weak arguments.
I think the problem with Git itself is enforces a lot of stuff (to my understanding of it) of how to work with the repo.
One of the thing that I could think of: The design itself comes with the idea you should clone the whole state of the version control to your machine instead of working through a lightweight API. This enforces you to download infinite-size of repo code (or even subdirectory using git sparsecheck out) instead of the solution at google which is requesting on demand i.e. NFS like iCloud drive/Google drive/Dropbox drive. On such solution, you could scale your repo size horizontally.
Hence to this limitation, it would enforce you to create a separate repo to deal such issue. The problem with having too many repositories are (again to my understanding), the lack of maintenance or update on repos that are not as often to be looked at but still requires it to keep running/alive
@@willysoesanto2046 you can specify a depth when cloning. However, the git man page is headed with "git - the stupid content tracker", so it is admittedly not super advanced -- it does its one thing using POSIX tools, and it does it quite well considering the price tag.
the real problem with git is that it’s wildly unintuitive, but no one knows how to make something that’s more intuitive without losing power and flexibility. I have to wonder what system Apple uses
The problem I have with this take is that he defends it with a circular argument.
"Git is bad because it doesn't scale. Git doesn't scale because it forces large companies to host hundreds of thousands of repos. Hundreds of thousands of repos is bad because it doesn't scale well."
The issue here is that he failed to make the case why 100k repos is a bad thing. Nor does he make the case for why this problem is something that should he solved by the VCS directly. By contrast, the fact that you can scale your code base to host 100k+ repos seems to suggest that git scales just fine.
Out of curiosity, I went ahead and cloned down the entire torvalds/linux repo, with the FULL history of the Linux Kernel. Optimally, you should just shallow clone a repo that large, but I went ahead and cloned the whole thing to see how bad it really was. It took about ~2 minutes to clone down all 5GB of the repo. Some of the git commands actually took a second or two instead of being instant, but I think that might have just been my terminal emulator printing text slowly. Usually I'm not working with a git repo with that many files. It didn't checkout properly on Windows, so all the files were "modified", which probably contributed to some of the slowdown.
Still, for being on the wrong platform, and intentionally pulling the largest repo I know about, and using the wrong git commands, it still worked pretty well. I was able to get the oldest commits in the repo at 2005. Which is pretty dang impressive, that I can go inspect the contents of a commit that's older than some people in this comment section. I'm still not seeing the performance issues with git.
Background: At Google for 7 years.
Assuming that Git scales, you did get some stuff from having a single repo. Some things I can think of:
1. Tree structure (directories in a monorepo) are more intuitive than a flat list (lots of repos).
2. Easier to make changes that affect multiple repos/projects. Can be done in a single atomic change. Makes a lot of sense for shared components like proto/graphql/... schemas.
3. Can run E2E integration tests. Make a backend change that breaks the frontend? Should be caught with the frontend's testing. Especially useful if that component/backend is used by many other components.
4. Makes it easier to debug issues with upstream. I've had scenarios where it has been useful to edit a dependency for fixing my own code, the dependency's code, or performance. In multiple Git repos, there is a barrier to entry to tweaking a dependency, but in a true monorepo, you can debug almost any part of the stack.
@@alexlowe2054 Are you sure you got the ***FULL*** history?
You sure there is not a branch out there somewhere that has not yet made it to the repo you took?
Well, most developers _don't_ work in "world scale" codebases. 💁
imagine all the open source content of github in a single monorepo
“GitHub is a monopoly”
Don’t talk about Monopoly, guy who used to work at Google…
Also Git is open source, GitHub is a company. Don’t conflate the two and then get mad.
I think he's clearly not talking about those cases :)
@@carlosmspk Right. He's saying Git is crap because X, completely missing the point that his X is a special case.
To spell it out: Git may be crap for X, but that doesn't support his general statements. Git is _fine_ for many cases. If not, more peopple would search for and adopt/build an alternative. Or monetize what they've already built internally.
@@laughingvampire7555 Yeah, and why would you do that?
"All the companies that we work with that use git have 100,000 Git repos"
I don't think the case was ever made about how that stated problem is Git's fault? I don't get what's the through line in that argument, or how other tools could prevent this problems which seems to be a management issue, not a tooling issue.
came here to say this exact thing. git doesn't force you to make a repo for every script and small thing you need.
I think the reasoning there is that git simply can't support that many files under a single repo. But he also failed to explain why 100k repos is bad in the first place. Modularizing code has always been ostensibly a good thing, so why should we treat version control differently?
There is a repository for every copy of the code out there. Many programmers are doing more than one thing ( bug fixes/adding new features ) at a time. So they may want to have multiple copies of the code. Google has many, many programmers doing many, many things.
Trust me bro
One thing that always bugged me about Piper (and maybe this has changed since I left) was that I couldn't create a stack of changes for review (as you can with something like stgit), it serialized the review of CLs in a way that was really stifling. Steve Yegge is correct that when you arrive at Google and see all the stuff, you are kind of like, "Holy shit, the rest of the world is banging two rocks together compared to this!"
Yes, that has changed in the last 3-4 years.
@@gorgonzolapalustrehmm why do guy mean? GitHub inprovements?
This fella sure said a lot without making a single point. Basically, "Google's tools are better" "Why?" "Trust me bro" *leaves*
He complains about Git and GitHub, but does Google have alternatives that they only use behind closed doors?
I think that's what he is saying, they do have an alternative but just closed and used in Google Only
@@taku6157 oh got it. But, death to Git. I think it's too much.
@@taku6157 if it were that good, why won't google make it a product/service to make money with?
@@taku6157 I heard him gush about their internal source code indexer and other IDE functionality, which is clearly _not_ what git is about, so I'm very confused about his complaints.
No, google also uses git (e.g. chromium repo), but with massively huge monorepos (many GiBs), that makes git very slow (e.g. checkout - an hour, git status - minutes). This is manageable with advanced git features (sparse and partial checkout) and finetuning, but it takes time to set up. It's inefficient thus not scaling. It's a pain to work on those codebases even at google. They lessen the pain by using expensive SSDs, CPU and lots of RAM: throwing metal at the problem.
But he's not talking about that. He's talking about code analytics, traversing (cross-referencing), and a build pipeline that catches errors and has the tools to dig into it quickly and effectively. Writing code is not efficient. Verifying and debugging the code is.
So the main argument is that Git offers difficulties with massively scaling up. Here's a thought: What if I work at a small company that doesn't need "planet scale"? Am I permitted to be happy with a tool that (almost) perfectly suits our needs?
Sure, companies that actually have those kind of problems should maybe use a different tool that better suits their needs. That's what competent engineers do after all - carefully selecting the right(-sized) tool for the job. But my bet is that such a hyper-scalable tool, whatever it may be, would probably do WORSE at scaling DOWN.
"It doesn't scale"
"How so?"
"Companies have like a bajillion git repos"
"...what?"
What do you mean, what?
@@antred11 what are you confused about
I want to see a demo! I love industry folks with this kind of insight. I've never had a problem with Git, so it's never occurred to me how the tooling could be improved, and it sounds interesting.
Right, really makes me think we are just happily banging away at rocks. xD And what else is "secret" programming knowledge ha
You should have seen how terrible I was with mainstream tools after I left my contracting job at Google. I felt like a beginner having to learn how to use subpar version control tools, testing libraries and IDEs
well the diffing is made with standard unix diff, and is just on text, there is not awareness of the language, sometimes the diffs are just too stupid.
conflict resolution, 3-way merging, binary files, etc. check another source control "pijul" tackles some issues with git.
This is interesting as I'm certainly still banging on rocks here.
if Google's tools are so epic where are they? Are you open sourced?
Actually git need to stick closed only for linux kernel purpose, u really don't need it on daily basis, u use it because of agile crap, which still don't know why u are using it, or git, or react and every other crap. Git submodules sound cool but is crap, I'm using every other tool available for greenfield project, not just git.
I know the journey along Google's historical support for their own products is littered with corpses. But if this is widely acknowledged as a Github killer, why don't they launch it as a rival offering themselves? You're leaving money on the table guys.
The only problem I am confronted to, while using GIT is instead diff.
diff compare text files as plain text files, without knowledge on languages and their syntaxes, and it's the main problem every GIT user will encounter on day-to-day use except if alone.
Easiest argument against git is that it’s basically unusable on any large project without github and that allowed OpenAI to have a huge learning codebase for AI to automate jobs away.
No, that's not an argument. Gitlab and other front-ends for git exists, and it allows keeping the codebase internal while still removing a lot of the pain that using plain git would involve.
Every company that I've worked for so far, in the last 10 years, has managed to keep its code on its own servers, without needing to resort to uploading to a third party like Github.
@@nistecuvinteoarecare that doesn't mean u pass the scaling issues.
The scaling part is problematic, but the real issue with Git is that the commands so complex they're tough to learn, it's effectively like learning a new programming language, similar difficulty curve for most devs. AI makes Git bearable.
Wait?! people overusing a product is a fault of the product?! Steve might be a great software dev, but this sounds like he had a bad day on a project, and ranted it all the way to this episode. This rant makes him look like Grandpa Simpson... Or is he jealous because he didn't create git? Being overused seems like a good problem to have/solve...
Also, all the neat features on top of git like indexing can be done thanks to git hooks. I feel like he doesn't really understand how distributed systems can systematically evolve.
yeah these guys are just grumpy xD
Git is good because it distributes control to the coder/programmer/engineer (Yay me!). Git is bad because of exactly the same problem (Hiss management !).
And yes, the cli (command line interface) is a bit vi/vim/ed/unix. And yes, sometimes you need a wui (s/windows/graphics user interface) to see what's going on. If only we nailed our other foot to the floor we could stop going around in circles. Who is version control actually for?
Thanks for the insight and skepticism of Git. I have long felt we could do better, in particular why does Git cause so much grief? Using git is like writing code in assembler. It is so low level, so easy to screw things up for yourself and/or your team. Why can't someone come up with something safer and more productive to just do the basics? Why can't we have a high-level source control system the minimizes cognitive load, and maximizes safety and mental health? Yes, Git made some huge improvements, but has rested on its laurels for too long.
In particular, using 'rebase' is like playing Russian Roulette.
@@EricKolotyluk And regular weeby developers don't know to write few git commands, really u don't need it, even u build 100+ microservices, it's just hype.
i don't understand the hate comments? Git is very a old technology ,people just become used to git existing problem and its still isn't going to change anytime soon.
he didnt make any sense at all, no real arguments, no real examples, anything, he just doesnt like git lol and he is loud about it
First exposure to Yegge and I gotta say I'm not impressed. A bajillion repos is an organizational issue. Monopolies are a systemic issue, meaning in another universe, Github would still be what it is, just built on Mercurial. The fact that some company has proprietary internal tooling that's great is basically meaningless for most SWEs, who incidentally are not working on world scale code.
And honestly to say that 'developers love Github too much' and then being so lukewarm on an Atlassian product is hilarious.
Never let perfect be the enemy of good enough
Never let good enough be the enemy of better.
Downloading off of GitHub awful
I always dismiss criticism that does not offer the "how it should be done" alternative. Superficial, useless and empty criticism.
same like your ukraine
LOL you're saying Git is bad because Google used it in a way that's not ideal which didn't allow them to scale well. Oooooooooookay... well use it right then?!
U are using microservies on daily basis because scaling, but microservices really don't scale well. U are using git because someone told u, but u never ever experience scaling issues, which he says. So that's why in 2024, we talking about hyped git, hype jira, hyped react and everything it's just hype, but nothing scales, even damn blockchains.
@@MrEnsiferum77 exuse me, what are you saying? Git is used in multiple companies because it allows you to collaborate on code within one or more huge codebasis in a single repository. This is not about scaling microservices either. This is about the claim that was made in the video about how Git doesn't scale well across huge codebasis. Nothing about hype whatsoever.
@@cheebadigga4092 still can't scale and can't rebase 100+ merge conflict files on it's own with ease. and i'm talking all modern tooling and technology today can't scale, it's just hype.
@@MrEnsiferum77 I don't know how to deal with you.
100000 repos?
Which companies do have so many repos? I mean seriously, which companies? OK, even if I assume that some companies have 100000 repos, how exactly is that git's fault? And what alternatives do you have to manage 100000 repos? Seriously! this guy is intellectually dishonest.
Doing some back of the envelope calculations, we probably have roughly 100k repos where I work, but while not FAANG scale, it is a 30k employees software company with tons of products, not exactly your small startup either. And that was counting it fairly generously, including forks and a lot of dead repositories containing things like one-off migration scripts used ten years ago. I also never deeply felt this was an actual issue, at most it's just a symptom of the organizational issues experienced by most companies of that size.
@@kakwa Thanks for also mentioning that the counting is done generously. Still did you count it, or just a wild guess?
Anyway, my point is that even if a company has thousands of repos, it does not mean that programmers work on all or most of them. Even a big companies like Amazon/Google, the engineers work on a couple of dozens of repos only, not thousands. Even then these dozens of repos are grouped differently based on the tasks they accomplish.
Number of repos usually do not matter. The size of a repo matters and I do not think there is a better tool than git to handle big repo size.
I don't think Git is bad technology per se but the UI is poor. And I don't mean just the command line tools but the way the workflow and the terminology is built around its internal data model. When humans create stuff they don't think in terms of directed acyclic graphs and they can't be expected to know what "detached head" means. They want to make their work public and they want to undo the changes if necessary. Another disadvantage of Git is the cost. Nearly every company has to employ a Git specialist who knows how to clean up the mess which is quite easy to create by the way. Too much wasted time and energy just for the sake of version control.
This honestly tells me more about the general quality of engineers and not the tool. If you have a woodworking shop and need "specialists" to operate and clean the lathe, it means you hired mediocre woodworkers. You don't throw out the lathe! If your software engineers create bazillion repositories and can't figure out basic git terminology, you hired mediocre coders with substandard computer science knowledge.
@@Lttlemoi Or maybe instead of spending time an engineer can figuring out the latest features of C++ ( rolling eyes ), or scriping gdb with python, or ... . Which one do you think a manger would rather have their SE's do?
Linus is the best software engineer ever. If he writes a tool, it's one of the best tool ever, period. Now if you come up with a better tool after 30 years, it doesn't mean that git is bad, it's just evolution. Git was meant to be better than the CVS at that time and it sure was, they weren't in the same league. And now someone on youtube is criticizing linus without showing an alternative. Want something better than git? Code it yourself, after all you say you're better than Linus.
No it's not, it's just hype over git, best developers were way before, just plain c and assembly and fly me to the moon. Linus was the crying about merging conflicts, and he only brings merging conflicts with git on daily basis, because of weeby developers.
@@MrEnsiferum77 you're disrespecting him and dismissing git like it's not that important.
The issue is git is one of the most important projects ever, and Linux is definitely the most important sodtea ever, guess who wrote that, And Linus made over $150m and NASA uses git and Linux.
I'm sure there are better devs than Linux like Terry and RMS, but they're both poor and teery died homeless. Linus is a winner at everything, the others are just nerds who can't get a wife and can't take care of themselves or their family.
you see, the code you write is meaningless, we might be the last generation to write code anyway, what matters is leaving behind a software that people use. 99.999% of the Linux and Windows and Mac and git users haven't sver seen the code behind it and it never matters
That includes you, you haven't seen the code for the moon project maybe it's shitty. and the moon project itself while it's super cool, it's not useful at all, that's why we haven't repeated it. it was just a pissing contest with the soviets
@@elieobeid77 See the problem is, u are saying we are last generation we write code... No can stop me from writing code to fly on the moon. People went to the moon with assembly code, while Linus that disrespect svn/scm centralized solutions becuse he can't merge his own code he wrote. Doom game was merged without git , svn or other solutions, but just merging HDD's, yes HDD's and they have perfect 0 day production, that u can't do it with git. If something is overreused doesn't mean is great. React was used for Edge, also NASA, does that mean anything? React is overused and it's crap, but still weeby kids using it on daily basis, when scalability hits, it's the developers fault, not the tooling we using.
When me and u will surprass scalability issues git have, we can talk is great, other than that, git rebase and git commit on daily basis, doesn't mean u need to use it. And the comments about nerds and homeless they dies, there are developers as any other, maybe they are not liberals at nature, so they don't give a f**k about modern tooling and systems. U believe that hyped AI is the future, but still u need that nerd kernel developers (that will die homeless and can't find girlfriend) that write code for that crap Linus, even hardly u can't find kernel developers that like to write linux code, AI can't do that, so the future of git and linux is not that bright.
@@MrEnsiferum77 I wrote a long reply and the OP of this video deleted my reply to make you seem correct, that's bullshit, I'm not going to rewite my comment, you go agree with the video poster and clap for yourselves
@@elieobeid77 Bro talking facts, he is not working on liberal web apps crap, u just falling of the chair that someone build tool for his own problems, and because you are using it u introducing yourself new problems. U will never ever lose time to rebase 100+ files at deadline, because git can't help u.
I had to write a library to manipulate commits in order to make git usable (ie, make commits algebraically operable).
I'm genuinely curious what do you mean under "make commits algebraically operable". Mind you give some details to somebody with pretty basic math knowledge?
that's not an argument against git
Yeah, that sounds interesting. Care to share your library?
So what exactly is your problem with git? "it doesn't scale", sure, but you don't explain what that means. How does a source code indexer in an IDE have anything to do with git? Git just does the versioning. That's the purpose of the tool, that's what it does and nothing else.
You know what really doesn't scale? Always synchronizing everything behind someone's back! The directed acyclic graph model is fantastic for scaling large codebases.
It's like people saying capitalism is bad without having a better solution. It's the best we git man
no, u never experienced real problems with git, git rebase and git commit on daily basis isnt the reason u need git on projects
@@MrEnsiferum77 what's wrong with git rebase and git commit? I think it's pretty simple to use. Also, what's your solution instead of git?
such a bad take
I made my own version control software, git is BLOAT 1
well, how can github scale, is written in rails.
Well then if he just would have said Github is bad for scale he might have a point. But Git is written in C and there are many types of tools and UIs based on Git
when the language make sense for scaling issues, u are dumb or something
Steve Yegge speaking nonsense! Unless he has better system, he is speaking nonsense. All other alternatives are inferior to git.
mercurial is far superior, really u don't need git, i've been so much more in git s**t , than help me... jus try to rebase 100+ files and git show how dead is