People who use git in monorepos don't understand git
We shrunk our Javascript monorepo git size
201–210 of 226 posts
Re: We shrunk our Javascript monorepo git size
#202Earlier quoted context omitted.
Can’t we split the packages into logical groups and maybe have 20 or 30 monorepos of 70-100 packages? I doubt that all the devs involved in that monorepo have to deal with all the 2500 packages. And I doubt that there is a circular dependency that requires all of these packages to be managed in a single monorepo.
People act like managing lots of git repos is hard, then run into monorepo problems requiring them to fix esoteric bugs in C that have been in git for a decade, all while still arguing monorepos are easy and great and managing multiple repos is complicated and hard. It's like hammering a nail through your hand, and then buying a different hammer with a softer handle to make it hurt less.
Don't forget that git was made for Linux and Linux isn't a monorepo and works great with tens of thousands of devs per release
Re: We shrunk our Javascript monorepo git size
#203Earlier quoted context omitted.
I'm the one who set it up. It's a small team of 20 people. I've done basically no setup beyond the minimum of following docs to get things running. We've had nonstop problems like this since the very start. Files don't upload, anytime I try to fix it I'm confronted with confusing error messages and cryptic things like people telling me "something related to EDR". What the hell is EDR? I just want to view a Word doc.…
EDR: https://en.wikipedia.org/wiki/Endpoint_detection_and_respons... I mentioned that because security software blocking things locally or at the network level is such a common source of friction. I don’t think Teams is perfect by any means but the core functionality has been quite stable in personal use, both of my wife’s schools, and my professional use so I wouldn’t conclude that it’s hopeless and always like that…
Thank you, I appreciate the support. But this doesn't explain the intermittent nature of the issues. For example, just now I tried to open a word file. I got the error message. But then I tried several times and restarted the app twice, and eventually the file did load. It just took five+ minutes of trying over and over.
I also had to add a new user yesterday, so I went to admin.microsoft.com in Edge. 403 error. Tried Chrome and Firefox. Same. Went back to Edge and suddenly it loaded. The like an idiot I refreshed, 403 error again. Another 5 or six refreshes and it finally loaded again and I was able to add the new user. There's never any real error messages that would help me debug anything, it's just endless frustration and slowness.
Re: We shrunk our Javascript monorepo git size
#204upd: silly mistake - file name does not include its full path The explanation probably got lost among all the gifs, but the last 16 chars here are different: > was actually only checking the last 16 characters of a filename > For example, if you changed repo/packages/foo/CHANGELOG.md, when git was getting ready to do the push, it was generating a diff against repo/packages/bar/CHANGELOG.md!
> file name does not include its full path No, it is the full path that's considered. Look at the commit message on the first commit in the `--full-name-hash` PR: https://github.com/git-for-windows/git/pull/5157/commits/d5c... Excerpt: "/CHANGELOG.json" is 15 characters, and is created by the beachball [1] tool. Only the final character of the parent directory can differntiate different versions of this file, but als…
Thanks for the deep dive!
Re: We shrunk our Javascript monorepo git size
#205Earlier quoted context omitted.
Why? You do realize their fork is open source? The fix described in this post have been submitted as a patch to the official Git project. The fix is improving a legitimate inefficiency in Git, and does nothing towards "embracing", "extending", or "extinguishing" anything.
Can you imagine their fork extending git with a feature which is incompatible to mainline git and then forcing user's to switch to their fork via github? I can, and it will give them the power to extinguish mainline git and force everything they want on their users (telemetry, licence agreements, online registration...). That might be the reason they're embracing git right now. The fork being open source doesn't help…
There is no fork. It's some new stuff they're working on and have sent patches to upstream git for (and will presumably get merged in due time – or at least, it's certainly written with the intent to get merged upstream).
https://lore.kernel.org/git/7d43a1634bbe2d2efa96a806e3de1f1f...
Re: We shrunk our Javascript monorepo git size
#206Earlier quoted context omitted.
People act like managing lots of git repos is hard, then run into monorepo problems requiring them to fix esoteric bugs in C that have been in git for a decade, all while still arguing monorepos are easy and great and managing multiple repos is complicated and hard. It's like hammering a nail through your hand, and then buying a different hammer with a softer handle to make it hurt less.
Don't forget that git was made for Linux and Linux isn't a monorepo and works great with tens of thousands of devs per release
> Linux isn't a monorepo
I assume you meant to write "is" there?
Re: We shrunk our Javascript monorepo git size
#207I think the title misses the "Honey, " part
Re: We shrunk our Javascript monorepo git size
#208> For many reasons, that's just too big, we have folks in Europe that can't even clone the repo due to it's size. What's up with folks in Europe that they can't clone a big repo, but others can? Also it sounds like they still won't be able to clone, until the change is implemented on the server side? > This meant we were in many occasions just pushing the entire file again and again, which could be 10s of MBs per fil…
I can actually weigh in here. Working from Australia for another team inside Microsoft with a large monorepo on Azure devops. I pretty much cannot do a full (unshallow) clone of our repo because Azure devops cloning gets nowhere close to saturating my gigabit wired connection, and eventually due to the sheer time it takes cloning something will hang up on either my end of the Azure devops end to the point I would just give up.
Thankfully, we do our work almost entirely in shallow clones inside codespaces so it's not a big deal. I hope the problems presented in the 1JS repro from this blog post are causing similar size blowout in our repo and can be fixed.
Re: We shrunk our Javascript monorepo git size
#209Earlier quoted context omitted.
They will extend git so that it works extremely well with their proprietary products, and just average with other tools and operating systems. That's always the goal for MS.
You know who the maintainer of Git is right?
Junio Hamano. Or did you confuse git and GitHub?
Re: We shrunk our Javascript monorepo git size
#210Earlier quoted context omitted.
What european countries still dont have fiber? //Confused swede with 10G fiber all over the place. Writing from literally the countryside next to nowhere.
I pay 42USD for 250Mbit in a larger Swedish city. What is that magic ISP I should be using?
Sounds like you are already using a magic ISP (rural USA here).