Every single time I've had to deal with a public-facing google tool I've wanted to rip my eyeballs out of my sockets. I shudder to imagine their unrefined internal tools
Im not sure what he means. I have worked on chromium and we used commands but those commands were wrappers around git commands + other things. Maybe google only uses those tools that he speaks of in internal projects?
I can easily believe that they have better tools than the rest of the world because they are competitive as a software house with a very long history of creating complex software. There is no surprise here. However, I feel like the guy was just rambling.
@@MrEnsiferum77developers who did not use version control systems in the 90s were trash developers not worthy of being mentioned. We had CVS ffs, and RCS before tbat.
@@vitalyl1327 U are stupid and u sound like crap liberal... just try to find out.... one of the most iconic games is done on different HDD's and then mergeed manually (copy paste) the code on release day... and boom... works everything perfect...
@@MrEnsiferum77 as an "old" developer I remember with horror how bad our source control system was, and how often people broke the build. Git is miraculously reliable by comparison (especially if you use CI)
@@Frozander I feel Steve Yegge 100% on this one, especially when he drops that "Ugh!" It may be because, when I was beginning to learn how to program, I had no idea what "version control" was, let alone a notion of why such a thing would be useful, let alone experience with it (like some people do with SVN, Perforce, Mercurial etc.) Git was frustrating: I had to learn an entirely new and complex system _on top of_ that of learning to program, like building a spiffy penthouse on top of an already-completed five-story apartment building. Trying out Fossil was a revelation for me: Fossil has a built-in GUI that lets you see - and by "see", I mean *see* - your development branches. I think it was then when a bird's-eye view of what version control actually is, clicked for the first time. Then, while doing the Odin Project, I came across this amazing Git tutorial, which I wholeheartedly recommend to everyone: learngitbranching.js.org/. Finally, using Magit makes using Git a fun experience, because of the actionability of Emacs buffers. I probably can't do full justice to it here, so I refer the reader to emacsrocks.com/e17.html, the Magit episode of the "Emacs Rocks" series.
@@luvincste most "more advanced" programming "stuff" is unintuitive the first time. That's not an argument at all. Or is quantum physics bad now because it's unintuative...
@@Cranked1 Quantum Mechanics is pretty much unintuitive. But if you stop thinking of its implications and focus in solving the linear algebra it is surprisingly easy at first. Of course that depending on initial conditions you can get a system that will take forever to solve. But by learning it in college I have a simple tip: Learn the math. See how its used in the real world, like with DFT. Them, after you know how the systems work and built some intuition, try and fit it to your model of the world. Visualize the wave function of the electron in atoms and molecules the way chemists do: as orbitals. Think of electrons as an electron orbital, that is composed of an electron wave-function in a potential well. Quantum mechanics, according to our understanding of the world (unless you're superdeterminist) is literally impossible to really visualize. How do you visualize a probability wave in 3 dimensions? And don't get me started in wave function collapse on observation - I don't know if it is clear, but in this sentence visualization and observation are totally different things (not a native English speaker). One observation: I took Quantum Mechanics in this semester. I don't know yet if everything I said is correct, but this framework of thinking made Quantum Mechanics less overwhelming to me. Edit: Probability waves are hard to visualize because it is weird to think of the fundamental theory of particles as something that could be (a probability) and not something that IS. For people it is very hard to understand probabilities as a real measure of things with real life consequences. It's easy to imagine a coin flipping. It is hard to imagine that a coin itself is made of probability waves. Of course, this way of thinking varies to interpretation of the facts. The probabilistic interpretation is the default they teach in college and it is a basis for every other interpretation. I am a firm believer that you have to have a strong basis before choosing your way to view the world as a Physicist. Obs.: I am here because I do Computational Physics and like programming in general.
@@Cranked1 To me, the difference is that quantum physics is so complicated that it can't be simplified or "improved". It's just fundamentally complicated and unintuitive. Version control is not even on the same scale of complexity. When I'm using git there are times when I can clearly picture the result I'm looking for, but getting there is needlessly complicated and unintuitive. One example is if I wanted to merge in some, but not all of the changes between two branches. It's doable, but feels more complicated than it should be.
That was my thought too. He does seem to be referring to "number of repos" with "scale" though, which... is a non-obvious take that it would have been nice to have elaborated upon.
According to Facebook in the announcement of Sapling three-quarters of the 5.5 GB Linux kernel repo is the history, and they say that with Sapling it only download what it needs allowing to work with repositories that may be terabytes in size.
@@danielsan901998 Git can do that too lol. (Though, I can certainly see an argument that git should probably make it the default behavior for repos past a certain size, rather than requiring you to manually specify it with a `--depth` argument when cloning.)
@@danielsan901998 Git are design for Linux Kernel in minds, it need to be fast even repo is very large (as long as disk/connection is fast enough), and able to work completely offline. If sapling does download only it needs, then it may design with different goals.
Very confusing. This had "old man yells at clouds" vibes in the first part and some google shilling in the second one. "I wanted to share with y'all that google devs can program tools and stuff, isn't it cool?"
First part, yes. Second part, intriguing. There's a point where lots of quality-of-life improvements in the development process would add up. If they've really optimized that environment and require everyone at Google to use it then how could it be bad? It'd probably rock the socks off everything and the more time you give to developers to use their expertise solving difficult problems or conversing with teammates on those problems by spending less time pushing buttons... I'm intrigued.
This guy is the programming equivalent of Comic Book Guy from Simpsons. "Worst. Source Control. Ever." (then doesn't explain why or give concrete examples)
Like the old days MS obsession, that guy sounded like he been on the drugs too long, not a single advantage he mentioned, Google's new integrated Dev tool is VSCode
🤯 How do you manage to do anything in Javascript with only 10 files? I seem to end up with about 4500 dependency files before I even start doing any coding.
If he worked for me and described issues this way without any semblance of cogent thought and analysis - he would have a much harder time getting my attention next time.
The one at fault is whoever decided on a microservice architecture, but doesn't trust any of their teams to maintain their own repos, so there is at least one team (or worse, person) that has to monitor all 100000 repos. Or, the microservices have already devolved into hellish interconnected spaghetti, and now all teams need to understand each of the 100000 repos.
@@kidmoseyYou dont have to make repositories public. Also git isnt github and git isnt peoples lack of control. That problem would (and does) exist on any free public facing repository service ... it always has.
He’s probably talking about the entire workflow at google. It’s super easy to do things. You have an internal web based IDE, it’s integrated into the internal version control system which is custom built to handle Google’s monorepo and handle thousands of changes at once, once you make a change it opens it up in the custom code review tool (which to be fair is very nice) and then once it’s approved you just hit submit and runs all tests when checks. You also don’t need to set up your testing pipeline since the google custom server framework handles all that for you. It’s very hard to break that up and sell it since for one piece to function seamlessly you need everything else as well
That seems nice. But the natural question is how much of that workflow is a feature of the tools themselves, compared to how they are managed and configured?
What I'm thinking then is that the massively superior part of the tooling in regards to versioning control specifically is that it can be a "live" environment, somewhat like what Google does with their office apps, and then everything feels "effortless" to clone, check-out, merge, test, commit etc etc etc.
That sounds pretty similar to what GitHub and some other companies offer these days, with codespaces. In fact it sounds like exactly the same thing. But in most software teams you don't need to work on that many different projects that setting them up locally is that big of a deal, plus you get to work with your own editor/tools and can work offline.
So basically something nobody would ever need or use outside of the Google bubble, plus it's so "custom" that it will never work outside of Google intranet. Alright, I'll stay with Git
I remember when I joined my team they used SVN but had no clue about how to do basic version control right. Basically everyone made their own folders and then they would copy and paste the code into a single "master" folder. No one even knew how to check in changes or anything. It was just a glorified file share. I managed to teach them proper version control strategies and make them go to Git. Life has been better since.
Ya, what gets me, is when you can't even talk about why something is better that isn't even available to the public let alone anyone outside of a singular place/company/location/etc, and actively crying about someone liking a toool because it's 'good enough' though it could be better. Like, sorry bro.... that tool is sooo unavailable that ... the response is.... 'so fing what'? The tools you're dogging on so hard, barely able to explain what's wrong with it while the few available tools you say are slightly better, you don't even give a phantom of a reasoning. Like this seriously just sounds ALOT like sour grapes. and is pissed that something gets used in maybe sub-optimal ways but ends up being good enough & robust enough for it to not matter for the majority of people. We can all qq about github & privacy... but .... hoiw many would be willing to forkout for bandwidth, data storage, data access, & world wide access for their own hosting & storage, oh yes and some how establish it as reasonably trustworthy enough to be recognized as a place to visit safely. Seriously though, If git isn't good enough, then just what the fuck in version control do you exactly bloody want? I have a few git issues from time to time, but really it's nothing but by implementation most the time on my end, and even if it could be improved, there is something to be said about enforcing workflows and data checkout/in security along with knowing what code you do & do not use without checking. Seriously though, Google might have the best tools on the planet for version controlling, but it kinda don't really matter really honestly if no one but google see's it & no one can really put it to it's paces really. That also said how much is the tooling, and how much is it the procedures & practices around version controlling use.
The only thing that really intimidated me about Git early in my career was the scope of the tools features, but it didn't take long to realize that only a small amount of the API is needed to get 90% of the value. In terms of scale, I've worked at what I consider a medium sized company with 100 - 200 developers and didn't find scale issues that I'd associate with Git.
TBF git really has: - a lot of inconsistent command line arguments, - overlapping commands and subcommands - Submodules (as mentioned in the video) are terrible to keep in sync with root repos - Branches, tags, commits, merges & rebases do not play well with each other (that's why there's so much written about 'the one true git workflow' etc.). - The web interface is feature poor and not 'modern' (which is why github, gitlab, bitbucket etc, all exist) - Hooks are painfully limited - CI tends to be built separately on top of all of it (because hooks can't do enough, apparently) - the internal model used means that a lot of commands over relatively small changes do a lot of upload and download that is part of the scaling issues - the internal model scales badly (uses a lot of memory and data for relatively small doc bases) I'm sure there's more but it's not really my wheel house, I'm only have a few years of experience with git.
It's true that Git doesn't scale to very very large sizes. Fundamentally though, very very large sizes are just not something that is supported by any alternative. It's certainly not SVN. Yes, having multiple repos linked together kind of sucks. But again what's the alternative then? Maybe just managing billions of files in one repo is just not a good idea (note, millions are just fine).
@@johnyewtube2286Microsoft too. They've used some patch for it to be better. I still don't understand how can programmers that love to separate everything in different files that each has different functions dumped everything in just one repo.
YES A compare feature that doesn’t require actually making a pull request. I love the way a diff helps think about the changes you’re making but I don’t want to have to make a request to get one
I remember programming inside a HP-UX hell in 2003 and thinking to myself "what if we could manage software versions through a tool?". Then I found out about RCS and it was even packaged for my OS :) Wait until you hear what I felt when I encountered SVN for the first time! Those were the days.
I use RCS for my writing projects and Git for my programming projects. I run my own Gitolite server for Git-managed projects and stopped using GitHub years ago.
You forgot CVS in between :) Each of these was such a step up. Git too. But it doesn't feel fundamentally different, each generation just fixed some problems from the previous one.
And worse: They're proprietary and not particularly friendly to open source AND the UI is internal only too and separate. So... there's just no way to get it outside
From a perspective of game developer: - Git is not good at handling binary files (e.g. game assets: textures, models, etc.) and doesn't have file locking for such files - Git can't effectively checkout specific parts of the repo (e.g. assets of specific level or one specific asset) - Git is a bit slow on large repos (e.g. FTP Game that operates 10 years on the market). I remember we had to strip part of the old history to make git responsive and clone faster (by default git stores entire history) Otherwise git is a perfect choice and a good tool. The scale they're talking about is unreachable for most of the devs. Those who needs scale builds it's own version control systems (e.g. Google, Yandex).
There were some pieces there nothing clear but this reminds me what I suggested in my module on the university where were we playing around with git and svn. Wouldn't be cool when the version control system would understand the language I write in ?(10 years ago) The reason was instead of committing files I would commit functions. Which would greatly reduce version conflicts. The prof didn't understood the benefits. In the next level you would also track the all global variables and where they came from and auto check them too. Your graphs then also show then the changes on your functions and who did it. This certainly need processing power but in theory you can make some kind of auto header file where name ,start and end of the function is in which with each commit gets updated. There is no need to update everything all the time. By the way you also want to support comments otherwise you would end up with what Tom did.
well if your dvcs is specific to a programming language, then you have to change your dvcs if you use a different programming language. What you are talking about actually does exist though for a programming language called unision. The code itself in its native form is a sort of structured dcvs. For instance if you reference a variable, a reference to the variable is whats in the code base, not a string representing that reference. All of the names are stored separately and in association with the referenced code structure, not the referent code structure. So there is a single source of truth about the relationship between names and the part of your program they symbolize. if you rename a declaration, those changes are automatically propagated to all prior references in the code base and it doesn't actually change the code as stored. The main database only actually cares about structural differences. The names are only used to identify new references in code changes, and to render existing code out for editing.
IBM had IDE (IDEs?) like that back in 90s, I think I was playing with one for Java, you didn't have to specify file name or file structure, you just added new functions/classes and the IDE automatically exported that into files for compiler creating the file structure on its own. On the tiny exploration projects I did it felt as great idea, but left some bad feel about "this will be total pain when things doesn't work as expected", now with git versioning source files this would probably blow up. The real point of this comment is that some thought like this were already tried, if you would pursue this idea and dig into CS history, you could probably find enough stuff to explore for couple of months and to see if there's enough substance to build further in this direction, or there are inherent issues which prevented this tech to pick up. I'm not sure why the IBM thingy was pretty much unknown BITD, I think the commercial price may have been one of stoppers (I got my hands on it as I got it as price in some programming contest), but that wouldn't stop whole industry from adopting the ideas if it was truly great, so there were probably deeper issues? I did play with it only for very limited time, and I don't recall any details any more, sadly.
GIT is a godsend compared to centralized version control systems especially Microsoft's TFS. Visual Studio, not Visual Studio Code, had a horrible integration for years and will constantly break. Of course the Microsoft sheep devs were too stupid to use the command line so they always thought git was just crappy
I "lost so many hairs" with TFS some years ago. Even when it was obsolete, we were using a certain IDE we were paying license for ONLY to connect and use TFS. Then we did all the actual work on another IDE we paid the licenses for. We complained, low management complained, middle management complained, high management wouldn't budge. TFS is basically the M$ embrace and extend of SVN.
@@brunoais "They are nice yes but quite incomplete" That is fine IMO. CLIs are almost always more feature-rich than GUIs anyway. What I need from a GUI for source control is just an interface for the most common commands and some visualization aids (for diffing, graphs, etc). I'm fine falling back to the CLI for more complex operations.
2:07 sounds like a skills issue to me 6:51 internally developed tools are usually janky in some way or another and more brittle than an inch thick layer of rust
He's right about some aspects. Git is terrible once you have many many repos and large binary file dependencies. Git LFS needs to be baked in and improved on. As does multi-repo commands.
Git is complex but not awful, lots of repo is not a problem from git. Those guys speak about Github like it’s just a motor to see PR and analysis it. Git is great and for now I didn’t see alternative not a super set of git repository.
I have never resonated more with an opinion more in my life. Git is a unintuitive mess where the basic actions and tasks you do were named without consideration for others. It was almost built to confuse people who want to learn it. What blows my mind is a pull request does ZERO PULLING it's you merging your changes into the main branch (PUSH MAKES MORE SENSE) GAAAAAAAAHHHHHHHHHHH
The main problems with Git from my perspective (hobbyist/student dev) are: 1. It prefers "quirky" nomenclature over descriptive/intuitive nomenclature. 2. In a lot of ways, Git does a very bad job of abstracting its "backend" functionality. Ever tried to *git rebase -i* with a nonlinear history? It can't even figure out how to reword commit messages without merge conflicts that if you're not *incredibly* careful will ruin your entire branch history and force you to reset and start the rebase from scratch. That being said, I don't personally think I could make anything better, but I do think there are plenty of people who could. Unfortunately Git is too conventional, there will never be another VCS that takes over, at least not in the forseeable future.
I think the root issue is that there are no such "intuitive way" of version controling in general. Git's backend is very simple if you take some time to understand it though.
@RealRatchet What you're describing is an entirely different form of rebasing. What I am talking about is rebasing a branch onto itself, which is used for things like squashing and rewording commits. The reason that people use rebase is not only because they feel it is more "correct," it's because many Git tools do not work properly on a non-linear history.
@JOHN-um2 I once asked some highly-experienced programmers (30+ years of experience, much of it using Git) how to bulk reword my commits and they said "give up and format your commits properly in the future."
12:30 I'm right there with you. For me, out of all the SCMs that have been described to me, Git is the best. Maybe that will change in the future, but if you just keep telling me that some piece of software is better then at some point you're going to need to explain the how and the why of it so that I can actually evaluate your opinion.
The main problem with git is that the terminology is off-the-charts bonkers (quick example, you want to undo local changes? git reset --hard HEAD. Wut? Ignore that you know what each of those bits mean for a second, imagine that you're coming at this completely fresh. A "hard reset" sounds like it would nuke the entire repo, but is actually an extremely common operation, if not the most common. Lots of the git "porcelain" has problems like these where the name of the feature seems at odds with what it's actually used for, which helps make the learning curve for using git effectively fairly steep. Some of the difficulty is inherent to version control being a "hard problem", but the git UX is really not that great. Another gripe I have with git is that it's very easy to create inscrutable tangles of branches because there's no prescribed structure (see e.g. the merge vs rebase debate). It takes a lot of discipline to keep a history understandable. Again, part of it is inherent to the problem, but is there nothing the tool itself can do to help? I'm unconvinced. Saying it needs to die is pretty weird and hyperbolic though.
@@Martinit0 pull requests are a github thing, not git. and the name describes exactly what's happening: you request someone with write permissions to pull in your changes
I think large part of git's complexity is an inherent consequence of its distributed nature. Why does setting up a remote need to include so many steps? Because git isso much more than "that command you use to push stuff to github", or at least it can be. Version control is a complex problem, distributed version control even more so. Sure the cli could be more intuitive, can't argue with that. I guess the question is, is the distributed model worth the hassle? The way most people use git, I don't know if it is. But on the other hand, being distributed means it can never be truly vendor locked, and it brings incredible flexibility. Like, we're used to having reliable high speed internet. But there might yet come a day when keeping local backups of repos in-house might be something we're damn thankful is a trivial thing to do.
One issue with mutliple repos (which TBF is not a Git problem) is that making a PR against many repos at once is largely unsupported. Being forced to make synchronized changes to multiple repos is painful.
currently the most promising vcs I have seen are pijul verifying changes and if I remember correctly undoing a commit will work always. and two Fossil its NOT made for large systems which is why its gaining traction for open source its always synced, and has a UI built in its nice, and is a standalone single executable, which recently I needed for a job I did. completely different the Unison programming language has there own version of Git built into the language, guarantees you are using the correct version of each function, and every function is hashed by functionality, its very cool looking and made for distributed programming, even if the language doesnt blow up I hope other languages copy the tech its very interesting.
Git gets the job done well, but (IMO) the problems are poor syntax (sometimes), too many "alternative" ways to command the same thing, and shitty error reporting. The whole system should get rewritten to use intuitive commands, provide excellent DX, and give deeper error logs that actually tell you what happened when there's a problem.
I love it when someone can speak for so long and say so little. Maybe the rest of the world would get to where google is at if: 1. They even know where Google is at, no one seems to actually describe it. 2. Anyone describes how they got there, no one ever seems to do this either. It's nice to long for a better world but if all you ever say is "gee why doesn't anyone do this?" and you are one of the few people that actually knows what they are doing and how then maybe it's up to you to do it?
The guy sounds eerily like Jonathan Blow. Both in vocal aspects, but also how he trashes everything implying that what he is doing is so much better without giving a concrete improvement points. Cynicism + Narcissism at its finest.
I like Gerrit, used by google, for its pull request system. You push the exact code you wrote as a packet and not the whole branch. You can do anything with the branch, for push/rebase/merge different things, they won't make any difference, because it only sees what's new between the main and this branch, and push that piece. they call it patchset.
@@Ruhrpottpatriot With Github, you still need to push the whole branch (and everything associated with it, example, logs, commits, rebases) which makes it ugly when you had to redo some things, but it ended up changing the hashes of your old commits that you've already pushed. This would require you to force push the branch and the whole PR thread gets messed up, example reviewers' chats/comments are now above these old commits (having new hashes). There's a awful amount of rules you need to follow to never arrive at a force push situation. With Gerrit, you never have to worry about these things. You don't ever get to situation where you would need to force push at all, because you never push the branch! the cli will orangise the changes into a patch on the client and then push it. Gerrit also simplies how the reviewers are notified about the new changes. It turns basis. You push the changes, pick the right reviewer, and ask gerrit to send them a notification. Once the reviewer approves the code. YOU merge the changes. No case of pre mature merging, which can happen in github, where "Open" PR doesn't indicate if it's ready to be merge or you are still fixing some bugs (Ofcourse, you can read the whole thread to get a sense whether it's ready or not). These are just few examples where Gerrit "way" seems to be better a way of managing PRs.
@@y7o4ka Maybe I'm missing something, but how do you send this patch (made with git-format-patch) to github as a PR so someone could review it and eventually merge it to main? Git is not the problem, Github is.
I loved Perforce on this subject, particularly its P4V GUI utility. Liked it so much I memorized and practiced its keyboard shortcuts. I still remember Ctrl+D to diff changes to individual files in P4V. That is honestly something I've viewed as a step backwards switching over to Git - the lack of similar Keyboard Shortcuts and as straightforward capabilities, instead I have to Command-line diff changes relative to an earlier version because I can't just select 2 in a GUI and then Ctrl+D to Diff the two. Also, I liked Shelve more than Stash because it could be shared without having to Commit, also it's stored Server-side unlike Stash that's not necessarily even available to other users because it's in a User's Local Repo.
I've used Google Piper it's not that great. And this idea they git doesn't scale is just absurd. You don't need to have thousands of repos, and most companies simply don't have that many. It also doesn't help that this guy doesn't really provide any kind of reason why Piper is better than git. There are pros and cons with both tools, and it really depends on how you want to structure your code bases.
How they talk to eachother....just really reminds me of a joe rogan episode where the guest tells joe that he saw aliens and they are going to harvest us
14:29 For me, this is definitely *not* a versioning problem. It's a pure *indexing* problem. I don't see why you can't have _Git_ or anything else for versioning side by side any sort of super-clever IA for indexing, search and diagnostics, working *with or without **_Git_* . _Git_ does only one thing and it does it well. If you want more features that have nothing to do with versioning, just build them. Where does it conflict ? I don't know.
…unless… *Unless **_Google_** don't work with files anymore* and work with *pure atomic relational data* , just like with the alternative file-less, directory-less OS I imagined but never built, and would like to use. In that case, if files aren't a thing anymore, yes, I understand why they don't want to bother using a tool like _Git_ that is specifically designed to version files and nothing else. Is _Google_ as advanced as what I have in my head since 2005 ? Maybe. I really don't know. I never worked for them and most probably will never be recruited by them, for obvious social reasons. If you work or worked for _Google_ , you tell me.
4:10 Valve : Proton Valve : Steamdeck Valve : Dxvk System76 : take your pick System76 : take your pick System76 : take your pick AMD : "fuck you FSR for everyone" You *_can_* extrapolate out self interested reasoning for all of this, but at that point I'd take another issue with this claim entirely and say literally no-one has ever "just been really great for no reason" because at the end of the day people do it because they think it's right and get personal satisfaction from doing what they think is the right thing. If you got zero satisfaction from doing the right thing and utterly despised it and got genuinely nothing out of it, you wouldn't do it. If you want to say things like Proton or the Steamdeck or FSR being completely open are self interested then fine, I'll agree with you if this conversation is operating on technicalities, but in that case then this sentiment applies to everyone-and-thing, not just companies.
I'd like a version control system that was lsp aware. If two people branch off master, and branch 1 moves a method to another spot within a class, and branch 2 is modifying that method, then someone gets a merge conflict later on. That's 100% avoidable if the diff engine was looking at syntax trees rather than just plain text. And you can take that simple idea and go a lot further with it, recording editing instructions rather than text changes in VCS, but that gets way out there.
It is absolutely wonderful to agree with ThePrimeagen on something. And I often agree with Yegge. It's a great feeling. Is this what it's like? (For context I'm an enterprise (small e) Java developer, who don't hate the language, but also have never had the more insane AbstractFactoryFactoryBean stuff people complain about.)
Git is the javascript of DVCS systems. Bazaar and Mercurial were both better user interfaces but the ecosystem settled on git. Github also has the worst history viewer. The whole point of branches and merges is having a visual tree. Having everything flat by default in the history, and burying the tree view in a *horizontal* viewer 3 menus deep where you have to mouse over each dot to see what they are.. Why can't they just have the history just show the history!
Many forms of source control have been tried, and will be tried in this world of sin and woe. No one pretends git is perfect or all-wise. Indeed it has been said that git is the worst form of source control except for all those other forms that have been tried from time to time.… Winston S Churchill, 11 November 1947
I tried out Fossil because of that video, I like that staging isn't a thing you just commit and it has some useful web tools implemented, but the way it's setup is arguably more awkward than git especially the init process which is suddenly two steps instead of one and for some reason it keeps it's files in two places instead of one like git. Also Fossil is a step backwards for me because Fossil's UI just isn't as great as my current setup of using git + GOGS on my server. It just doesn't deliver on the polish and ease of use like one would hope but it does have some some technical benefits over git in other areas.
@@paradox2579 So basically like SVN in that regard. It would never work well for me because I usually do much and then I need to split into commits. Thanks for the answer.
I’ve used git and perforce. I think git has advantages for programmers, but if you’re working with multiple disciplines, locking files and shelving in p4 is so much better.
So what the dude actually says is that... Git doesn't scale well enough to handle the world's largest codebases. Ok, but for the rest of us who don't have to deal with anything that big Git works just fine. So for me what this dude says is... not relevant at all. Never was.
If google is so good at understanding large codebases, how come they gave up on fixing memory errors in chrome and decided deliberately leaking memory would be a better idea? The quality of their public code output does not seem consistent with this supposed superpower.
Pijul & darcs use patch theory to eliminate a subset of issues with merging. When patch A then B is C & patch B then A is often also C, but Git requires that the order matters giving merge conflicts that shouldn’t cause issues.
I wonder if Spotify's Backstage framework is an example of what he is talking about. It's not source control, but it's a discoverable platform for the entire company's repos, projects, documentation, templates, etc. He was referring to the problem of thousands of repos and Spotify seems to have a good solution for it.
0:26 commands like "git checkout" can do something **completely** different depending on the arguments it has, come on man xD this is why software like Gitkraken exists, git's back-end is fine but using it for the CLI can be scary when you are not 100% sure what you're doing (especially with commands like git checkout, which can rewrite the history tree)
Mmmm… I’m gonna need you to show me what options to `git checkout` can “rewrite the history tree”. Yes, there are git commands that can rewrite version history and remove entire subtrees from all history, but those are not `git checkout`. Personally, I don’t trust most Git UIs that try to make the details of git actions easier because they frequently don’t do what I want. I am an almost 100% git command line user and prefer being explicit in some “common” commands because not doing so has bitten me at some point in the past.
Personally I feel like Git is extremely good from a technical (behind the scenes) aspect but its frontend (the commands) are a god damn mess. There are so many ways to do the same thing, none if them makes sense for a first time user. The terminology only makes somewhat sense if you understand a bit how it all works and very common cases are confusing as hell (you git add a file you just deleted, what?) Dangerous commands are a few flags away from really helpful ones (hard vs soft reset the last commit) and many mores issues. I feel like someone should just write and actually useful somewhat interactive wrapper for git. Ideally it should be approachable for non software devs like various engineers, office workers and so on with some technical skill. Best case you actually have a GUI application where you can draw the changes you want in the usual graph tree and then it does that via commands in the background.
Except its very complicated, git is really good for text files, but does not know how to merge blob, so it is useless for office worker and engineers, Office worker tend to used the integrated version history if there is one, Engineers/Artist I suppose tend to send copy of their work as you need a software or use some kind of dependency system if available and compose things by the end (ex: Blender / Unity) So to be fair Git is almost only usefull on codebases as most CVS. Maybe extending git fonctionnality via some kind of plugin to be able to deal better with those "blobs" might make things easier but yeah, I was confused almost all the way along because the guy in the video does not seem to be able to make the difference between git and github, especially since even Chromium codebase use Git
@@HinaraT "the guy in the video does not seem to be able to make the difference between git and github" ... yep, you nailed it. That's exactly why what he's saying sounds so incoherent. He says git, but he means github. He contrasts the supposed google tools that make you coffee and rub your balls with git, but what he really means is github.
What made Google's scm system good was that you didn't have to git clone a repo with 1B+ lines of code amd tools built ontop of it. But most companies aren't that big and use a monorepo.
The only critique I have for git is that it promotes companies to create multiple repos for stuff that could just be monorepos. If hit had a better submodule / subtree workflow I think git would be perfect. Monorepos ❤
Honestly with the way CI/CD tools work, I much prefer single repo per service container. Mono repos force you to make assumptions about the other services, but if they were so similar they should just be a monolith, not multiple services in the same repo.
Submodules are the right idea for the wrong product. The implementation is bad because git is bad. And they're only needed because git can't handle inter-product dependencies or nested projects.
The first source control program I ever used was Microsoft's Visual SourceSafe. It used a library paradigm: When you want to make a change, you "check out" a file, make a change, and check it back in. When it's checked out, nobody else should check it out to modify it. This paradigm made so much sense to me that it's ruined me for any other source control paradigm. I constantly have to unlearn it when using Git.
What he is hinting at is "mono-repo" + "trunk based development" at global scale. The reason he's not saying much seems to be that he wants to or is already developing something for it and doesn't want to let others in on the problems and solutions. Any real world project that has to work at scale has too many repos to manage, especially if many separate teams are doing it. Repos depending on each other complicates things further! So companies like Google (and Facebook) have developed tools to manage all the code as a mono-repo and follow trunk-based development.
99% of the time you need are a few commands: Bread and butter: git init git add (normally just with .) git commit -m "Commit message" git reset (often just HEAD~1 to rollback your last changes) git push git fetch git merge/ rebase Occasionally useful commands: git log git stash Very rarely you might need something else either to fix a problem by looking into the reflog or do something specific like an octopus merge in your tooling but for the vast majority its just that list above. Are you really telling me that its going to take you a long time to learn
At one point somebody says something like "it's the worst option, apart from everything else", which IMO is a completely fair and correct take. There probably isn't an overall better free and general purpose option, but at the same time it feels incredibly sub-par and janky for something that is so widely and prominently used. One example: LFS (still) not having branch-scoped locking support makes what should be considered a critical feature of version control virtually unusable. But I don't know of an alternative that implements this properly. SVN, for example, usually prevents this issue from arising in practice, but only by making branching too unwieldy to use in normal circumstances, which is an even worse trade-off. I can believe that Google should have the resources to make something better. But the quality of their public APIs makes me skeptical that they actually do.
Mercurial has a bit nicer UX (thinking back many years when I last used it), but it's very similar to git in a lot of respects and it's written in Python. Though I think they replaced parts with Rust now? Was it Rust?
Ironically I think git is shit compared to mercurial, but I switched from mercurial in 2019 because git has a good support for big binary files (*1), also it was too slow because it was written in python. Now that it's rewritten in Rust I might go back to mercurial. (*1 yes, I store binary files, its machine learning models, its "code" that runs the application, so it goes together with , process me )
I love how every senior engineer is literally set in their ways, extremely rigid and all have their own quirks. My old boss said its easier to have a team of clueless juniors develop stuff than like 5 senior engineers who are all set in their ways and dig in their heels
I think that the reason why git seems complicated is because it's actually like, 4+ different tools rolled into one. On one hand, it's serves the purpose of revision control. The management of a singular timeline, to which you can commit changes, revert them, or reset to an earlier point in time. Secondarily, it serves the purpose of version control. In this case, you have multiple different versions of the same project. When built on top of revision control, each version of the project has some sort of shared history, with the others, but effectively branches off into it's own timeline that's completely adjacent to the others. Combining two versions requires their timelines to be merged, which can be done by replaying all the changes that have been made since the moment the timelines forked from each other, i.e. re-basing the changes on a different version of the code, or by simplying squashing all of the changes into one single change that can be applied, i.e. git merge. Thirdly, git serves the purpose of interfacing with a distributed system. The ability to specifiy the origin of a repository and push changes to it or pull them down. It's this push and pull system that coordinates everyone with each other. N-thly, git just a bunch of other arbitrary crap that's highly specific. Stashing changes and reverting, tracking which files have changed since the last commit, figuring out who screwed up what, creating and applying patches, etc. Tbh, git is a lot closer to being a source code control system than a version control system.
Just imagine the Google employees, floating around in their spheres of crystalline neon glass, creating the code of the future by the flick of a hand, so that we can see the perfect embodiment of stupidity in the next NFT or daytrading or quack philosophy master class ad for 4 seconds before we click on to the next video to mindlessly consume. What a time to be alive.
that doesn't manage the repos, it just associates them with each other. They still have to be independently managed. The way you normally do this if you actually want to maintain an in tree copy of what may have started off as a separate repo, while still maintaining upstream history, is git subtree. Probably doesn't scale to a 1000 subtree project with 10 jiggawatts of history in each.
Next week: Prime start at Google, playing with google tools for 2 days. the following week: Prime join TJ, and cry about GIT and other tools for the next year.
As someone who finds frustration with a dozen work repos, he's spot on. I spend so much time complaining to other teams who have made some change to one repo, but haven't updated another repo to match, who then block me from merging my changes, because the dependency is messed up. It's completely obnoxious. I can't imagine how bad 100,000 repos would be, with teams of the size of 1000s. I want to know how other people work that having so many repos just isn't a problem they even understand.
This is a problem with the company's process for updating code, not with git. The issue would be solved if a process existed to ensure code in other repos is updated before merges take place.
Company disagreements and inefficiencies on how you group code into repos has nothing to do with the tools that deal with the repos. Design/planning issue.
@@robertharris4129 So if git had tooling to support multiple repos, then the problem would go away, but it's a tooling issue and not a git issure. The cope is crazy.
This fellow said a lot without really saying anything at all.
i worked at google btw, you wouldn't understand
@@isaac_shelton I worked at understand btw, you wouldn't google
He's good to work at a PR department of google.
Bro be like skill issue
"git is terrible, google's tools are like science fiction compared to the rest of the world!"
*refuses to elaborate*
*leaves*
Every single time I've had to deal with a public-facing google tool I've wanted to rip my eyeballs out of my sockets. I shudder to imagine their unrefined internal tools
ever tried using anything from GCP ? I bet he's lying
Im not sure what he means. I have worked on chromium and we used commands but those commands were wrappers around git commands + other things. Maybe google only uses those tools that he speaks of in internal projects?
@@monad_tcp I've tried AWS, Azure & Oracle, I don't think they're any better.
the reason why he was probably layed off from google team is that he is pretty dumb, hiring him was a waste of money. 🤣
All I got from this is "Google has better tools, trust me bro"
They do. Just look at chromium repo.
He said nothing. It may be awesome but he said absolutely nothing.
You want a better VCS? I can get you a VCS, believe me. There are ways, Dude.
I can easily believe that they have better tools than the rest of the world because they are competitive as a software house with a very long history of creating complex software. There is no surprise here.
However, I feel like the guy was just rambling.
like gn and repo 🤷♂️
Git is the reason why our -10x engineer can’t do permanent damage to our build system
This is terrible explanation, just go back to 90's how they shipped games without tools like git.... without any versioning system...
@@MrEnsiferum77developers who did not use version control systems in the 90s were trash developers not worthy of being mentioned. We had CVS ffs, and RCS before tbat.
@@vitalyl1327 U are stupid and u sound like crap liberal... just try to find out.... one of the most iconic games is done on different HDD's and then mergeed manually (copy paste) the code on release day... and boom... works everything perfect...
... being a professional coder is already.. being damaged.
what's ur point ?
@@MrEnsiferum77 as an "old" developer I remember with horror how bad our source control system was, and how often people broke the build. Git is miraculously reliable by comparison (especially if you use CI)
Felt more like a career flex than any actual valid points
That's exactly what it was.. Sadly.
That's just cause you never used google tools 😆
Of course it is Yegge doing what Yegge does, Flex. He's so up himself.
Git is the only technology I use that I don’t hate and now you want to take it from me 😭
No one can take Git from you !!!
Let this be your Braveheart moment. Put war paint on your face and storm the hill with your two-hander !
Magit for Emacs makes Git intuitive and understandable
@@IrizarryBrandongit is not unintuitive for me. I never understood the "unintuitive" argument
@@Frozander I feel Steve Yegge 100% on this one, especially when he drops that "Ugh!" It may be because, when I was beginning to learn how to program, I had no idea what "version control" was, let alone a notion of why such a thing would be useful, let alone experience with it (like some people do with SVN, Perforce, Mercurial etc.) Git was frustrating: I had to learn an entirely new and complex system _on top of_ that of learning to program, like building a spiffy penthouse on top of an already-completed five-story apartment building. Trying out Fossil was a revelation for me: Fossil has a built-in GUI that lets you see - and by "see", I mean *see* - your development branches. I think it was then when a bird's-eye view of what version control actually is, clicked for the first time. Then, while doing the Odin Project, I came across this amazing Git tutorial, which I wholeheartedly recommend to everyone: learngitbranching.js.org/. Finally, using Magit makes using Git a fun experience, because of the actionability of Emacs buffers. I probably can't do full justice to it here, so I refer the reader to emacsrocks.com/e17.html, the Magit episode of the "Emacs Rocks" series.
I'm gonna guess you work on Ruby on Rails
He never really gave any reason why Git is bad. He just said it was bad and they decided he was right.
Yeah, it seemed like he meant to say just Github, but said Git too and rolled with it.
ha said it's unintuitive etc, and i agree
@@luvincste most "more advanced" programming "stuff" is unintuitive the first time. That's not an argument at all. Or is quantum physics bad now because it's unintuative...
@@Cranked1 Quantum Mechanics is pretty much unintuitive. But if you stop thinking of its implications and focus in solving the linear algebra it is surprisingly easy at first. Of course that depending on initial conditions you can get a system that will take forever to solve. But by learning it in college I have a simple tip: Learn the math. See how its used in the real world, like with DFT. Them, after you know how the systems work and built some intuition, try and fit it to your model of the world. Visualize the wave function of the electron in atoms and molecules the way chemists do: as orbitals. Think of electrons as an electron orbital, that is composed of an electron wave-function in a potential well. Quantum mechanics, according to our understanding of the world (unless you're superdeterminist) is literally impossible to really visualize. How do you visualize a probability wave in 3 dimensions? And don't get me started in wave function collapse on observation - I don't know if it is clear, but in this sentence visualization and observation are totally different things (not a native English speaker). One observation: I took Quantum Mechanics in this semester. I don't know yet if everything I said is correct, but this framework of thinking made Quantum Mechanics less overwhelming to me. Edit: Probability waves are hard to visualize because it is weird to think of the fundamental theory of particles as something that could be (a probability) and not something that IS. For people it is very hard to understand probabilities as a real measure of things with real life consequences. It's easy to imagine a coin flipping. It is hard to imagine that a coin itself is made of probability waves. Of course, this way of thinking varies to interpretation of the facts. The probabilistic interpretation is the default they teach in college and it is a basis for every other interpretation. I am a firm believer that you have to have a strong basis before choosing your way to view the world as a Physicist. Obs.: I am here because I do Computational Physics and like programming in general.
@@Cranked1 To me, the difference is that quantum physics is so complicated that it can't be simplified or "improved". It's just fundamentally complicated and unintuitive. Version control is not even on the same scale of complexity. When I'm using git there are times when I can clearly picture the result I'm looking for, but getting there is needlessly complicated and unintuitive.
One example is if I wanted to merge in some, but not all of the changes between two branches. It's doable, but feels more complicated than it should be.
If Google's internal documentation is so good, why are all the public docs so awful 😞
ikr? Their documentation is an abomination.
If google's ability to understand large codebases is so good, why is chrome such a steaming pile of dung?
@@isodoubIetI'm curious as to how bad things are under the hood. Chromium seems to Just Work™
@isodoubIet chrome-based browsers have 90% of the market share, I don't think steaming pile of dung is accurate
@@rutabega306Lots of people use a steaming pile of dung, yes. It's truly a terrible browser.
Git does not scale? How on earth are the Linux devs working with Git?
That was my thought too. He does seem to be referring to "number of repos" with "scale" though, which... is a non-obvious take that it would have been nice to have elaborated upon.
Very true
According to Facebook in the announcement of Sapling three-quarters of the 5.5 GB Linux kernel repo is the history, and they say that with Sapling it only download what it needs allowing to work with repositories that may be terabytes in size.
@@danielsan901998 Git can do that too lol. (Though, I can certainly see an argument that git should probably make it the default behavior for repos past a certain size, rather than requiring you to manually specify it with a `--depth` argument when cloning.)
@@danielsan901998 Git are design for Linux Kernel in minds, it need to be fast even repo is very large (as long as disk/connection is fast enough), and able to work completely offline. If sapling does download only it needs, then it may design with different goals.
Tom have a perfect versioning system, much better than Google's tool and git, he's a genius
Tom is the best SVN user
@@johnnycochickenthe *last xD
@@johnnycochicken Tom uses svn, mercurial, git and TFVC all at once. It is magnificent.
Very confusing. This had "old man yells at clouds" vibes in the first part and some google shilling in the second one. "I wanted to share with y'all that google devs can program tools and stuff, isn't it cool?"
First part, yes. Second part, intriguing. There's a point where lots of quality-of-life improvements in the development process would add up. If they've really optimized that environment and require everyone at Google to use it then how could it be bad? It'd probably rock the socks off everything and the more time you give to developers to use their expertise solving difficult problems or conversing with teammates on those problems by spending less time pushing buttons...
I'm intrigued.
@@x--.If it was that good they'd be selling it
This guy is the programming equivalent of Comic Book Guy from Simpsons. "Worst. Source Control. Ever." (then doesn't explain why or give concrete examples)
haha right, that's what I was thinking :P
Google obsession is not a mark of a useful software developer.
💯
Like the old days MS obsession, that guy sounded like he been on the drugs too long, not a single advantage he mentioned, Google's new integrated Dev tool is VSCode
I need world-scale for the repo with 40 commits and 10 javscript files
🤯 How do you manage to do anything in Javascript with only 10 files? I seem to end up with about 4500 dependency files before I even start doing any coding.
@@katrinabryce npm is hard, so I copy-paste all the dependencies in one file
@@korzinkoah. The ol manual esbuild
@@katrinabrycejs sucks ass biggest piece of shit software ok thx bye
@@katrinabryce You don't commit dependencies.
If he worked for me and described issues this way without any semblance of cogent thought and analysis - he would have a much harder time getting my attention next time.
He would most likely be fired
The real question is: whose fault is it that you have 100k repos? That's insane
As of 2021, they have 140,000 employees. It's not surprising at all that they would have 100,000 repos.
@@sullivan3503that's an average of 1.4 employees per repo
If we're talking active repos(not read-only) what kind of quality work is being done with
The one at fault is whoever decided on a microservice architecture, but doesn't trust any of their teams to maintain their own repos, so there is at least one team (or worse, person) that has to monitor all 100000 repos.
Or, the microservices have already devolved into hellish interconnected spaghetti, and now all teams need to understand each of the 100000 repos.
@@kidmoseyYou dont have to make repositories public. Also git isnt github and git isnt peoples lack of control.
That problem would (and does) exist on any free public facing repository service ... it always has.
This is yet again someone that can't think properly and blame git for the usage of it.
He’s probably talking about the entire workflow at google. It’s super easy to do things. You have an internal web based IDE, it’s integrated into the internal version control system which is custom built to handle Google’s monorepo and handle thousands of changes at once, once you make a change it opens it up in the custom code review tool (which to be fair is very nice) and then once it’s approved you just hit submit and runs all tests when checks. You also don’t need to set up your testing pipeline since the google custom server framework handles all that for you. It’s very hard to break that up and sell it since for one piece to function seamlessly you need everything else as well
That seems nice. But the natural question is how much of that workflow is a feature of the tools themselves, compared to how they are managed and configured?
What I'm thinking then is that the massively superior part of the tooling in regards to versioning control specifically is that it can be a "live" environment, somewhat like what Google does with their office apps, and then everything feels "effortless" to clone, check-out, merge, test, commit etc etc etc.
That sounds pretty similar to what GitHub and some other companies offer these days, with codespaces. In fact it sounds like exactly the same thing.
But in most software teams you don't need to work on that many different projects that setting them up locally is that big of a deal, plus you get to work with your own editor/tools and can work offline.
So what the hell it has to do with git itself?
So basically something nobody would ever need or use outside of the Google bubble, plus it's so "custom" that it will never work outside of Google intranet. Alright, I'll stay with Git
I remember when I joined my team they used SVN but had no clue about how to do basic version control right. Basically everyone made their own folders and then they would copy and paste the code into a single "master" folder. No one even knew how to check in changes or anything. It was just a glorified file share.
I managed to teach them proper version control strategies and make them go to Git. Life has been better since.
Ya, what gets me, is when you can't even talk about why something is better that isn't even available to the public let alone anyone outside of a singular place/company/location/etc, and actively crying about someone liking a toool because it's 'good enough' though it could be better.
Like, sorry bro.... that tool is sooo unavailable that ... the response is.... 'so fing what'? The tools you're dogging on so hard, barely able to explain what's wrong with it while the few available tools you say are slightly better, you don't even give a phantom of a reasoning. Like this seriously just sounds ALOT like sour grapes. and is pissed that something gets used in maybe sub-optimal ways but ends up being good enough & robust enough for it to not matter for the majority of people.
We can all qq about github & privacy... but .... hoiw many would be willing to forkout for bandwidth, data storage, data access, & world wide access for their own hosting & storage, oh yes and some how establish it as reasonably trustworthy enough to be recognized as a place to visit safely.
Seriously though, If git isn't good enough, then just what the fuck in version control do you exactly bloody want? I have a few git issues from time to time, but really it's nothing but by implementation most the time on my end, and even if it could be improved, there is something to be said about enforcing workflows and data checkout/in security along with knowing what code you do & do not use without checking.
Seriously though, Google might have the best tools on the planet for version controlling, but it kinda don't really matter really honestly if no one but google see's it & no one can really put it to it's paces really. That also said how much is the tooling, and how much is it the procedures & practices around version controlling use.
The only thing that really intimidated me about Git early in my career was the scope of the tools features, but it didn't take long to realize that only a small amount of the API is needed to get 90% of the value.
In terms of scale, I've worked at what I consider a medium sized company with 100 - 200 developers and didn't find scale issues that I'd associate with Git.
This guy is completely incoherent. His argument for why git sucks is basically just making guttural icky noises. Onomatopoeia is not an argument.
"Hammers are not very intuitive."
*Hammers self in face*
"See!!?"
TBF git really has:
- a lot of inconsistent command line arguments,
- overlapping commands and subcommands
- Submodules (as mentioned in the video) are terrible to keep in sync with root repos
- Branches, tags, commits, merges & rebases do not play well with each other (that's why there's so much written about 'the one true git workflow' etc.).
- The web interface is feature poor and not 'modern' (which is why github, gitlab, bitbucket etc, all exist)
- Hooks are painfully limited
- CI tends to be built separately on top of all of it (because hooks can't do enough, apparently)
- the internal model used means that a lot of commands over relatively small changes do a lot of upload and download that is part of the scaling issues
- the internal model scales badly (uses a lot of memory and data for relatively small doc bases)
I'm sure there's more but it's not really my wheel house, I'm only have a few years of experience with git.
It's true that Git doesn't scale to very very large sizes. Fundamentally though, very very large sizes are just not something that is supported by any alternative. It's certainly not SVN. Yes, having multiple repos linked together kind of sucks. But again what's the alternative then? Maybe just managing billions of files in one repo is just not a good idea (note, millions are just fine).
I read that Google uses a giant monorepo.
@@johnyewtube2286Microsoft too. They've used some patch for it to be better. I still don't understand how can programmers that love to separate everything in different files that each has different functions dumped everything in just one repo.
YES A compare feature that doesn’t require actually making a pull request. I love the way a diff helps think about the changes you’re making but I don’t want to have to make a request to get one
I remember programming inside a HP-UX hell in 2003 and thinking to myself "what if we could manage software versions through a tool?". Then I found out about RCS and it was even packaged for my OS :) Wait until you hear what I felt when I encountered SVN for the first time! Those were the days.
I use RCS for my writing projects and Git for my programming projects. I run my own Gitolite server for Git-managed projects and stopped using GitHub years ago.
When I first encountered TortoiseSVN, I thought it was named after a turtle because it was so incredibly slow...
You forgot CVS in between :) Each of these was such a step up. Git too. But it doesn't feel fundamentally different, each generation just fixed some problems from the previous one.
Google's tools are great, but come with a drawback most devs will consider a non-starter: no development offline
And worse: They're proprietary and not particularly friendly to open source AND the UI is internal only too and separate. So... there's just no way to get it outside
"Emotionally hurt me"
I dont think there has been any software that has not emotionally hurt someone to learn XD
>be google
>best tooling in the world
>can't do a fucking API documentation
Makes me wonder what tools Apple uses. Apple docs are much better.
"strager" made a Bun review. I think you should review his review! He does good videos, and even sets the license on the vids to creative commons :)
Yeah, that dude is something else... Gilfoyle irl 😂
From a perspective of game developer:
- Git is not good at handling binary files (e.g. game assets: textures, models, etc.) and doesn't have file locking for such files
- Git can't effectively checkout specific parts of the repo (e.g. assets of specific level or one specific asset)
- Git is a bit slow on large repos (e.g. FTP Game that operates 10 years on the market). I remember we had to strip part of the old history to make git responsive and clone faster (by default git stores entire history)
Otherwise git is a perfect choice and a good tool. The scale they're talking about is unreachable for most of the devs. Those who needs scale builds it's own version control systems (e.g. Google, Yandex).
You can clone without dragging the entire down..
What are you talking about?! Git lfs is perfect for handling large files and has file locking
"Everybody thinks submodules are going to be good"
Yes, i was that person once. Wholefully regretted introducing it in one of the projects.
but there is going to be yet another problem where it just makes sense... and then you hate it
No not everybody. Some people got told about them and their first reaction was "why the fuck would anyone want to do that?".
"slurp up all the data" 😂 I don't know if I love or hate this wording, lol
"Git is the worst version control system - except for all of the others that have been tried." - Wiston Churchill, maybe
There were some pieces there nothing clear but this reminds me what I suggested in my module on the university where were we playing around with git and svn. Wouldn't be cool when the version control system would understand the language I write in ?(10 years ago) The reason was instead of committing files I would commit functions. Which would greatly reduce version conflicts. The prof didn't understood the benefits.
In the next level you would also track the all global variables and where they came from and auto check them too. Your graphs then also show then the changes on your functions and who did it.
This certainly need processing power but in theory you can make some kind of auto header file where name ,start and end of the function is in which with each commit gets updated. There is no need to update everything all the time. By the way you also want to support comments otherwise you would end up with what Tom did.
well if your dvcs is specific to a programming language, then you have to change your dvcs if you use a different programming language. What you are talking about actually does exist though for a programming language called unision. The code itself in its native form is a sort of structured dcvs. For instance if you reference a variable, a reference to the variable is whats in the code base, not a string representing that reference.
All of the names are stored separately and in association with the referenced code structure, not the referent code structure. So there is a single source of truth about the relationship between names and the part of your program they symbolize. if you rename a declaration, those changes are automatically propagated to all prior references in the code base and it doesn't actually change the code as stored. The main database only actually cares about structural differences. The names are only used to identify new references in code changes, and to render existing code out for editing.
IBM had IDE (IDEs?) like that back in 90s, I think I was playing with one for Java, you didn't have to specify file name or file structure, you just added new functions/classes and the IDE automatically exported that into files for compiler creating the file structure on its own. On the tiny exploration projects I did it felt as great idea, but left some bad feel about "this will be total pain when things doesn't work as expected", now with git versioning source files this would probably blow up.
The real point of this comment is that some thought like this were already tried, if you would pursue this idea and dig into CS history, you could probably find enough stuff to explore for couple of months and to see if there's enough substance to build further in this direction, or there are inherent issues which prevented this tech to pick up. I'm not sure why the IBM thingy was pretty much unknown BITD, I think the commercial price may have been one of stoppers (I got my hands on it as I got it as price in some programming contest), but that wouldn't stop whole industry from adopting the ideas if it was truly great, so there were probably deeper issues? I did play with it only for very limited time, and I don't recall any details any more, sadly.
@ped7g yes. Visual age for java. VAJ lol.. I hated it at the time.
GIT is a godsend compared to centralized version control systems especially Microsoft's TFS.
Visual Studio, not Visual Studio Code, had a horrible integration for years and will constantly break. Of course the Microsoft sheep devs were too stupid to use the command line so they always thought git was just crappy
I "lost so many hairs" with TFS some years ago. Even when it was obsolete, we were using a certain IDE we were paying license for ONLY to connect and use TFS. Then we did all the actual work on another IDE we paid the licenses for. We complained, low management complained, middle management complained, high management wouldn't budge.
TFS is basically the M$ embrace and extend of SVN.
Git is fine on CLI but there are really good GUI for it. lazygit and Git Extensions comes to mind
@@brunoaisI know people here are not fan of vscode but vscode gui/menus for git are really good.
@@Frozander They are nice yes but quite incomplete in what git can do.
I do use vscodium for now so it's pretty much the same🙂.
@@brunoais "They are nice yes but quite incomplete"
That is fine IMO. CLIs are almost always more feature-rich than GUIs anyway. What I need from a GUI for source control is just an interface for the most common commands and some visualization aids (for diffing, graphs, etc). I'm fine falling back to the CLI for more complex operations.
2:07 sounds like a skills issue to me
6:51 internally developed tools are usually janky in some way or another and more brittle than an inch thick layer of rust
"I worked at Google so I'm right!"
"I worked at google by the way"
He's right about some aspects. Git is terrible once you have many many repos and large binary file dependencies. Git LFS needs to be baked in and improved on. As does multi-repo commands.
Git might have problems, but SVN and Perforce are orders of magnitude worse
Luckily there are alternatives to those 3
As someone who barely uses GIT... for the most basic use of "you now have an online backup and version history of your code" it's pretty intuitive
I feel like they're saying: You haven't met our God and savior, Google. Trust me bro. 😅
Git is complex but not awful, lots of repo is not a problem from git. Those guys speak about Github like it’s just a motor to see PR and analysis it. Git is great and for now I didn’t see alternative not a super set of git repository.
This has to be the worst conversation I have ever listened to
I have never resonated more with an opinion more in my life. Git is a unintuitive mess where the basic actions and tasks you do were named without consideration for others. It was almost built to confuse people who want to learn it. What blows my mind is a pull request does ZERO PULLING it's you merging your changes into the main branch (PUSH MAKES MORE SENSE) GAAAAAAAAHHHHHHHHHHH
The main problems with Git from my perspective (hobbyist/student dev) are:
1. It prefers "quirky" nomenclature over descriptive/intuitive nomenclature.
2. In a lot of ways, Git does a very bad job of abstracting its "backend" functionality. Ever tried to *git rebase -i* with a nonlinear history? It can't even figure out how to reword commit messages without merge conflicts that if you're not *incredibly* careful will ruin your entire branch history and force you to reset and start the rebase from scratch.
That being said, I don't personally think I could make anything better, but I do think there are plenty of people who could. Unfortunately Git is too conventional, there will never be another VCS that takes over, at least not in the forseeable future.
People obsessed with rebasing is the reason why git is annoying. Just use merge commits, it's more useful to have a true history than "nice" history.
I think the root issue is that there are no such "intuitive way" of version controling in general. Git's backend is very simple if you take some time to understand it though.
@RealRatchet What you're describing is an entirely different form of rebasing. What I am talking about is rebasing a branch onto itself, which is used for things like squashing and rewording commits. The reason that people use rebase is not only because they feel it is more "correct," it's because many Git tools do not work properly on a non-linear history.
@JOHN-um2 I once asked some highly-experienced programmers (30+ years of experience, much of it using Git) how to bulk reword my commits and they said "give up and format your commits properly in the future."
Yeah rebases and merges interact very poorly
12:30 I'm right there with you. For me, out of all the SCMs that have been described to me, Git is the best. Maybe that will change in the future, but if you just keep telling me that some piece of software is better then at some point you're going to need to explain the how and the why of it so that I can actually evaluate your opinion.
The main problem with git is that the terminology is off-the-charts bonkers (quick example, you want to undo local changes? git reset --hard HEAD. Wut? Ignore that you know what each of those bits mean for a second, imagine that you're coming at this completely fresh. A "hard reset" sounds like it would nuke the entire repo, but is actually an extremely common operation, if not the most common. Lots of the git "porcelain" has problems like these where the name of the feature seems at odds with what it's actually used for, which helps make the learning curve for using git effectively fairly steep.
Some of the difficulty is inherent to version control being a "hard problem", but the git UX is really not that great. Another gripe I have with git is that it's very easy to create inscrutable tangles of branches because there's no prescribed structure (see e.g. the merge vs rebase debate). It takes a lot of discipline to keep a history understandable. Again, part of it is inherent to the problem, but is there nothing the tool itself can do to help? I'm unconvinced.
Saying it needs to die is pretty weird and hyperbolic though.
Fully agree. It starts with the basics: A "pull request" is when you want to contribute code.
@@Martinit0 pull requests are a github thing, not git. and the name describes exactly what's happening: you request someone with write permissions to pull in your changes
I think large part of git's complexity is an inherent consequence of its distributed nature. Why does setting up a remote need to include so many steps? Because git isso much more than "that command you use to push stuff to github", or at least it can be. Version control is a complex problem, distributed version control even more so. Sure the cli could be more intuitive, can't argue with that. I guess the question is, is the distributed model worth the hassle? The way most people use git, I don't know if it is. But on the other hand, being distributed means it can never be truly vendor locked, and it brings incredible flexibility. Like, we're used to having reliable high speed internet. But there might yet come a day when keeping local backups of repos in-house might be something we're damn thankful is a trivial thing to do.
One issue with mutliple repos (which TBF is not a Git problem) is that making a PR against many repos at once is largely unsupported. Being forced to make synchronized changes to multiple repos is painful.
Sounds like poor architecture decisions were made. I don't see this as a git problem
That means the repos are very badly integrated with one another. Not an issue with git, but an issue with how you organized your source code.
@@Lttlemoi It's an issue with GitHUB. How do you propose making a single PR against multiple repos? You can't.
This why you use a mono repo like a grown up.
This guy blinks an absurd amount of times. Literally like every .4 seconds. You can't unsee it.
I am a little too happy that "tree-bucket" could totally be the name of a version control software.
I wouldn't say i like git, but it does it's job fine
currently the most promising vcs I have seen are pijul verifying changes and if I remember correctly undoing a commit will work always. and two Fossil its NOT made for large systems which is why its gaining traction for open source its always synced, and has a UI built in its nice, and is a standalone single executable, which recently I needed for a job I did.
completely different the Unison programming language has there own version of Git built into the language, guarantees you are using the correct version of each function, and every function is hashed by functionality, its very cool looking and made for distributed programming, even if the language doesnt blow up I hope other languages copy the tech its very interesting.
Git gets the job done well, but (IMO) the problems are poor syntax (sometimes), too many "alternative" ways to command the same thing, and shitty error reporting. The whole system should get rewritten to use intuitive commands, provide excellent DX, and give deeper error logs that actually tell you what happened when there's a problem.
Company I work at tried to do submodules. It didn't take till the end of the day for it to be scraped lol
Googles internal tools suck. Goole doesn't get developer platform. They don't even use gcloud themselves.
Can you link me to the articles that explains how google doesnt use gcloud please?
I love it when someone can speak for so long and say so little. Maybe the rest of the world would get to where google is at if:
1. They even know where Google is at, no one seems to actually describe it.
2. Anyone describes how they got there, no one ever seems to do this either.
It's nice to long for a better world but if all you ever say is "gee why doesn't anyone do this?" and you are one of the few people that actually knows what they are doing and how then maybe it's up to you to do it?
The guy sounds eerily like Jonathan Blow. Both in vocal aspects, but also how he trashes everything implying that what he is doing is so much better without giving a concrete improvement points. Cynicism + Narcissism at its finest.
I like Gerrit, used by google, for its pull request system. You push the exact code you wrote as a packet and not the whole branch. You can do anything with the branch, for push/rebase/merge different things, they won't make any difference, because it only sees what's new between the main and this branch, and push that piece. they call it patchset.
have you ever tried "git format-patch start..end"? Because that sounds like an aweful lot like git patches.
Gerrit is only used for external/open source Google stuff. Compared to Google internal tools, it is really bad.
Sounds really like format-patch and merge --squash
@@Ruhrpottpatriot With Github, you still need to push the whole branch (and everything associated with it, example, logs, commits, rebases) which makes it ugly when you had to redo some things, but it ended up changing the hashes of your old commits that you've already pushed. This would require you to force push the branch and the whole PR thread gets messed up, example reviewers' chats/comments are now above these old commits (having new hashes). There's a awful amount of rules you need to follow to never arrive at a force push situation.
With Gerrit, you never have to worry about these things. You don't ever get to situation where you would need to force push at all, because you never push the branch! the cli will orangise the changes into a patch on the client and then push it.
Gerrit also simplies how the reviewers are notified about the new changes. It turns basis. You push the changes, pick the right reviewer, and ask gerrit to send them a notification. Once the reviewer approves the code. YOU merge the changes. No case of pre mature merging, which can happen in github, where "Open" PR doesn't indicate if it's ready to be merge or you are still fixing some bugs (Ofcourse, you can read the whole thread to get a sense whether it's ready or not).
These are just few examples where Gerrit "way" seems to be better a way of managing PRs.
@@y7o4ka Maybe I'm missing something, but how do you send this patch (made with git-format-patch) to github as a PR so someone could review it and eventually merge it to main?
Git is not the problem, Github is.
I loved Perforce on this subject, particularly its P4V GUI utility. Liked it so much I memorized and practiced its keyboard shortcuts. I still remember Ctrl+D to diff changes to individual files in P4V. That is honestly something I've viewed as a step backwards switching over to Git - the lack of similar Keyboard Shortcuts and as straightforward capabilities, instead I have to Command-line diff changes relative to an earlier version because I can't just select 2 in a GUI and then Ctrl+D to Diff the two. Also, I liked Shelve more than Stash because it could be shared without having to Commit, also it's stored Server-side unlike Stash that's not necessarily even available to other users because it's in a User's Local Repo.
Git hater: you haven’t used google tools
Me: how can I, google code was shut down
be happy?
I've used Google Piper it's not that great. And this idea they git doesn't scale is just absurd. You don't need to have thousands of repos, and most companies simply don't have that many. It also doesn't help that this guy doesn't really provide any kind of reason why Piper is better than git. There are pros and cons with both tools, and it really depends on how you want to structure your code bases.
agreed, if you have a thousand dependency and they are not packaged then you did something fundamentally wrong
Back to banging rocks I guess.
And happily at that :)
How they talk to eachother....just really reminds me of a joe rogan episode where the guest tells joe that he saw aliens and they are going to harvest us
14:29 For me, this is definitely *not* a versioning problem. It's a pure *indexing* problem.
I don't see why you can't have _Git_ or anything else for versioning side by side any sort of super-clever IA for indexing, search and diagnostics, working *with or without **_Git_* .
_Git_ does only one thing and it does it well. If you want more features that have nothing to do with versioning, just build them. Where does it conflict ? I don't know.
…unless…
*Unless **_Google_** don't work with files anymore* and work with *pure atomic relational data* , just like with the alternative file-less, directory-less OS I imagined but never built, and would like to use.
In that case, if files aren't a thing anymore, yes, I understand why they don't want to bother using a tool like _Git_ that is specifically designed to version files and nothing else.
Is _Google_ as advanced as what I have in my head since 2005 ? Maybe. I really don't know. I never worked for them and most probably will never be recruited by them, for obvious social reasons.
If you work or worked for _Google_ , you tell me.
4:10
Valve : Proton
Valve : Steamdeck
Valve : Dxvk
System76 : take your pick
System76 : take your pick
System76 : take your pick
AMD : "fuck you FSR for everyone"
You *_can_* extrapolate out self interested reasoning for all of this, but at that point I'd take another issue with this claim entirely and say literally no-one has ever "just been really great for no reason" because at the end of the day people do it because they think it's right and get personal satisfaction from doing what they think is the right thing. If you got zero satisfaction from doing the right thing and utterly despised it and got genuinely nothing out of it, you wouldn't do it. If you want to say things like Proton or the Steamdeck or FSR being completely open are self interested then fine, I'll agree with you if this conversation is operating on technicalities, but in that case then this sentiment applies to everyone-and-thing, not just companies.
I don't know anyone who worked at Google and praised their internal tooling, only people who don't want to deal with them anymore.
I'd like a version control system that was lsp aware. If two people branch off master, and branch 1 moves a method to another spot within a class, and branch 2 is modifying that method, then someone gets a merge conflict later on. That's 100% avoidable if the diff engine was looking at syntax trees rather than just plain text. And you can take that simple idea and go a lot further with it, recording editing instructions rather than text changes in VCS, but that gets way out there.
This I agree with. Much of that problem could be handled with an external merge tool, but it would be nice if git had native plugin support, too.
Glad to hear I am not tge only one who doesn't like submodules
It is absolutely wonderful to agree with ThePrimeagen on something.
And I often agree with Yegge.
It's a great feeling. Is this what it's like?
(For context I'm an enterprise (small e) Java developer, who don't hate the language, but also have never had the more insane AbstractFactoryFactoryBean stuff people complain about.)
Git is the javascript of DVCS systems. Bazaar and Mercurial were both better user interfaces but the ecosystem settled on git.
Github also has the worst history viewer. The whole point of branches and merges is having a visual tree. Having everything flat by default in the history, and burying the tree view in a *horizontal* viewer 3 menus deep where you have to mouse over each dot to see what they are.. Why can't they just have the history just show the history!
Many forms of source control have been tried, and will be tried in this world of sin and woe. No one pretends git is perfect or all-wise. Indeed it has been said that git is the worst form of source control except for all those other forms that have been tried from time to time.…
Winston S Churchill, 11 November 1947
I tried out Fossil because of that video, I like that staging isn't a thing you just commit and it has some useful web tools implemented, but the way it's setup is arguably more awkward than git especially the init process which is suddenly two steps instead of one and for some reason it keeps it's files in two places instead of one like git. Also Fossil is a step backwards for me because Fossil's UI just isn't as great as my current setup of using git + GOGS on my server. It just doesn't deliver on the polish and ease of use like one would hope but it does have some some technical benefits over git in other areas.
Without staging, does that means you always commit everything?
@@brunoais It adds everything by default but you still have the option to manually specify what you want to add. It's mostly just a small nicety.
@@paradox2579
So basically like SVN in that regard.
It would never work well for me because I usually do much and then I need to split into commits.
Thanks for the answer.
man, ive discovered your videos a littel while ago, and i love you, svn hurt you, and also me, i feel you bro
TortoiseGit also exists
I’ve used git and perforce. I think git has advantages for programmers, but if you’re working with multiple disciplines, locking files and shelving in p4 is so much better.
So what the dude actually says is that... Git doesn't scale well enough to handle the world's largest codebases. Ok, but for the rest of us who don't have to deal with anything that big Git works just fine. So for me what this dude says is... not relevant at all. Never was.
If google is so good at understanding large codebases, how come they gave up on fixing memory errors in chrome and decided deliberately leaking memory would be a better idea? The quality of their public code output does not seem consistent with this supposed superpower.
i really don't think git is bad. but we probably could have a more modern implementation of version control
Pijul & darcs use patch theory to eliminate a subset of issues with merging. When patch A then B is C & patch B then A is often also C, but Git requires that the order matters giving merge conflicts that shouldn’t cause issues.
I wonder if Spotify's Backstage framework is an example of what he is talking about. It's not source control, but it's a discoverable platform for the entire company's repos, projects, documentation, templates, etc. He was referring to the problem of thousands of repos and Spotify seems to have a good solution for it.
0:26
commands like "git checkout" can do something **completely** different depending on the arguments it has, come on man xD this is why software like Gitkraken exists, git's back-end is fine but using it for the CLI can be scary when you are not 100% sure what you're doing (especially with commands like git checkout, which can rewrite the history tree)
Mmmm… I’m gonna need you to show me what options to `git checkout` can “rewrite the history tree”. Yes, there are git commands that can rewrite version history and remove entire subtrees from all history, but those are not `git checkout`.
Personally, I don’t trust most Git UIs that try to make the details of git actions easier because they frequently don’t do what I want. I am an almost 100% git command line user and prefer being explicit in some “common” commands because not doing so has bitten me at some point in the past.
@@ivanheffner2587 not reading all that. good for u though (or sorry it happened)
SVN was WAY more intuitive than Git. It was a simpler tool. An insufficient tool, but simpler nonetheless.
Personally I feel like Git is extremely good from a technical (behind the scenes) aspect but its frontend (the commands) are a god damn mess. There are so many ways to do the same thing, none if them makes sense for a first time user. The terminology only makes somewhat sense if you understand a bit how it all works and very common cases are confusing as hell (you git add a file you just deleted, what?)
Dangerous commands are a few flags away from really helpful ones (hard vs soft reset the last commit) and many mores issues.
I feel like someone should just write and actually useful somewhat interactive wrapper for git.
Ideally it should be approachable for non software devs like various engineers, office workers and so on with some technical skill. Best case you actually have a GUI application where you can draw the changes you want in the usual graph tree and then it does that via commands in the background.
Except its very complicated, git is really good for text files, but does not know how to merge blob, so it is useless for office worker and engineers,
Office worker tend to used the integrated version history if there is one,
Engineers/Artist I suppose tend to send copy of their work as you need a software or use some kind of dependency system if available and compose things by the end (ex: Blender / Unity)
So to be fair Git is almost only usefull on codebases as most CVS.
Maybe extending git fonctionnality via some kind of plugin to be able to deal better with those "blobs" might make things easier but yeah, I was confused almost all the way along because the guy in the video does not seem to be able to make the difference between git and github, especially since even Chromium codebase use Git
What you want is TortoiseGit.
@@HinaraT "the guy in the video does not seem to be able to make the difference between git and github"
... yep, you nailed it. That's exactly why what he's saying sounds so incoherent. He says git, but he means github. He contrasts the supposed google tools that make you coffee and rub your balls with git, but what he really means is github.
What made Google's scm system good was that you didn't have to git clone a repo with 1B+ lines of code amd tools built ontop of it.
But most companies aren't that big and use a monorepo.
The only critique I have for git is that it promotes companies to create multiple repos for stuff that could just be monorepos.
If hit had a better submodule / subtree workflow I think git would be perfect.
Monorepos ❤
No one uses submodules, at least in real life.
I've used submodules in the last 2 companies 🐿️
Honestly with the way CI/CD tools work, I much prefer single repo per service container.
Mono repos force you to make assumptions about the other services, but if they were so similar they should just be a monolith, not multiple services in the same repo.
submodules is good if you have like four of them and they are reliable enough you never have to touch them.
Submodules are the right idea for the wrong product. The implementation is bad because git is bad. And they're only needed because git can't handle inter-product dependencies or nested projects.
This guy never worked with TFVC, another brillian microsoft idea hahaha!
The first source control program I ever used was Microsoft's Visual SourceSafe. It used a library paradigm: When you want to make a change, you "check out" a file, make a change, and check it back in. When it's checked out, nobody else should check it out to modify it. This paradigm made so much sense to me that it's ruined me for any other source control paradigm. I constantly have to unlearn it when using Git.
The problem doesn't seem like it's about git, but more of a software deployment problem
What he is hinting at is "mono-repo" + "trunk based development" at global scale. The reason he's not saying much seems to be that he wants to or is already developing something for it and doesn't want to let others in on the problems and solutions.
Any real world project that has to work at scale has too many repos to manage, especially if many separate teams are doing it. Repos depending on each other complicates things further! So companies like Google (and Facebook) have developed tools to manage all the code as a mono-repo and follow trunk-based development.
trunk based development is great until you get power pegged
Git has like 50 ways to achieve the same result. Different combos of commands, flags, parameters… So many unique ways to make a footgun.
Lol. If you can't figure out .git, how are you a professional?
You mostly only need to use 10 commands in git for the most part, so sincerely just don't try being "the overengineering guy".
99% of the time you need are a few commands:
Bread and butter:
git init
git add (normally just with .)
git commit -m "Commit message"
git reset (often just HEAD~1 to rollback your last changes)
git push
git fetch
git merge/ rebase
Occasionally useful commands:
git log
git stash
Very rarely you might need something else either to fix a problem by looking into the reflog or do something specific like an octopus merge in your tooling but for the vast majority its just that list above.
Are you really telling me that its going to take you a long time to learn
At one point somebody says something like "it's the worst option, apart from everything else", which IMO is a completely fair and correct take. There probably isn't an overall better free and general purpose option, but at the same time it feels incredibly sub-par and janky for something that is so widely and prominently used.
One example: LFS (still) not having branch-scoped locking support makes what should be considered a critical feature of version control virtually unusable. But I don't know of an alternative that implements this properly. SVN, for example, usually prevents this issue from arising in practice, but only by making branching too unwieldy to use in normal circumstances, which is an even worse trade-off.
I can believe that Google should have the resources to make something better. But the quality of their public APIs makes me skeptical that they actually do.
Mercurial has a bit nicer UX (thinking back many years when I last used it), but it's very similar to git in a lot of respects and it's written in Python. Though I think they replaced parts with Rust now? Was it Rust?
Mercurial at least does not allow easily to shit in your history
Ironically I think git is shit compared to mercurial, but I switched from mercurial in 2019 because git has a good support for big binary files (*1), also it was too slow because it was written in python.
Now that it's rewritten in Rust I might go back to mercurial.
(*1 yes, I store binary files, its machine learning models, its "code" that runs the application, so it goes together with , process me )
@@monad_tcptry out git-lfs in your spare time. It's kinda like git, but for binaries 😅
To be honest, I'd pick mercurial even without RIIR (Rewriting it in Rust) @@monad_tcp
@@y7o4ka gonna try
I love how every senior engineer is literally set in their ways, extremely rigid and all have their own quirks. My old boss said its easier to have a team of clueless juniors develop stuff than like 5 senior engineers who are all set in their ways and dig in their heels
I think that the reason why git seems complicated is because it's actually like, 4+ different tools rolled into one.
On one hand, it's serves the purpose of revision control. The management of a singular timeline, to which you can commit changes, revert them, or reset to an earlier point in time.
Secondarily, it serves the purpose of version control. In this case, you have multiple different versions of the same project. When built on top of revision control, each version of the project has some sort of shared history, with the others, but effectively branches off into it's own timeline that's completely adjacent to the others. Combining two versions requires their timelines to be merged, which can be done by replaying all the changes that have been made since the moment the timelines forked from each other, i.e. re-basing the changes on a different version of the code, or by simplying squashing all of the changes into one single change that can be applied, i.e. git merge.
Thirdly, git serves the purpose of interfacing with a distributed system. The ability to specifiy the origin of a repository and push changes to it or pull them down. It's this push and pull system that coordinates everyone with each other.
N-thly, git just a bunch of other arbitrary crap that's highly specific. Stashing changes and reverting, tracking which files have changed since the last commit, figuring out who screwed up what, creating and applying patches, etc.
Tbh, git is a lot closer to being a source code control system than a version control system.
Just imagine the Google employees, floating around in their spheres of crystalline neon glass, creating the code of the future by the flick of a hand, so that we can see the perfect embodiment of stupidity in the next NFT or daytrading or quack philosophy master class ad for 4 seconds before we click on to the next video to mindlessly consume. What a time to be alive.
“How do we manage 100,000 git repos??”
How about git submodules?
How about not creating a submodule for each file in a project 🤔
that doesn't manage the repos, it just associates them with each other. They still have to be independently managed. The way you normally do this if you actually want to maintain an in tree copy of what may have started off as a separate repo, while still maintaining upstream history, is git subtree. Probably doesn't scale to a 1000 subtree project with 10 jiggawatts of history in each.
Oh god no. Not submodules.
Next week: Prime start at Google, playing with google tools for 2 days.
the following week: Prime join TJ, and cry about GIT and other tools for the next year.
As someone who finds frustration with a dozen work repos, he's spot on. I spend so much time complaining to other teams who have made some change to one repo, but haven't updated another repo to match, who then block me from merging my changes, because the dependency is messed up. It's completely obnoxious. I can't imagine how bad 100,000 repos would be, with teams of the size of 1000s. I want to know how other people work that having so many repos just isn't a problem they even understand.
but how is that a git problem and not a problem with how people work at your company?
Skill issue
This is a problem with the company's process for updating code, not with git. The issue would be solved if a process existed to ensure code in other repos is updated before merges take place.
Company disagreements and inefficiencies on how you group code into repos has nothing to do with the tools that deal with the repos.
Design/planning issue.
@@robertharris4129 So if git had tooling to support multiple repos, then the problem would go away, but it's a tooling issue and not a git issure.
The cope is crazy.
13:15 Loooooong minutes later… "What if we decided what we were talking about, now ?" ;D