Live data from Hacker News

We shrunk our Javascript monorepo git size

jonathancreamer.com

81–90 of 226 posts

Re: We shrunk our Javascript monorepo git size

#81
post #12

Earlier quoted context omitted.

In most EU countries we have multi-gigabit internet (for cheap too). Current offers are around ~5 GBIT speeds for 20 bucks a month.

Not in the UK. Still on 80Mbit VDSL here.

I and many I know have Gb fiber in the UK

Re: We shrunk our Javascript monorepo git size

#82

> We work in a very large Javascript monorepo at Microsoft we colloquially call 1JS. I used to call it office.com.. Teams is the worst offender there. Even a website with a cryptominer on it runs faster than that junk.

We were all impressed with google docs, but office.com is way more impressive. Collaborative editing between a web app, two mobile anpps and a desktop app with 30 years of backwards compatibility and it pretty much just works. No wonder that took a lot of JavaScript!

That's the thing, though, the compat story is terrible. I can't say much about the backwards one, but Microsoft has started the process of removing features from the native versions just to lower the bar for the web one catching up. Even my most Microsoft-enamoured colleagues are getting annoyed by this (and the state of all-MS things going downhill, but that's another story)

Re: We shrunk our Javascript monorepo git size

#83
post #12

Earlier quoted context omitted.

In most EU countries we have multi-gigabit internet (for cheap too). Current offers are around ~5 GBIT speeds for 20 bucks a month.

Not in the UK. Still on 80Mbit VDSL here.

You must be unlucky, according to Openreach "fibre broadband is already available in more than 96.59 per cent of the UK."

Re: We shrunk our Javascript monorepo git size

#84
post #61

> We work in a very large Javascript monorepo at Microsoft we colloquially call 1JS. I used to call it office.com.. Teams is the worst offender there. Even a website with a cryptominer on it runs faster than that junk.

Hey, I worked with Jonathan on 1JS a while ago (on a team, Excel). Just a note OMR (the office monorepo) is a different (and actually much larger) monorepo than 1JS (which is big on its own) To be fair I suspect a lot of the bloat in both originates from the amount of home grown tooling.

I thought Microsoft had one monorepo. Isn't that kind of the point? How many do they have?

Re: We shrunk our Javascript monorepo git size

#85
post #30

Thanks for this post. Really interesting and a great win for OSS! I've been watching all the recent GitMerge talks put up by GitButler and following the monorepo / scaling developments - lots of great things being put out there by Microsoft, Github, and Gitlab. I'd like to understand this last 16 char vs full path check issue better. How does this fit in with delta compression, pack indexes, multi-pack indexes etc ..…

> Really interesting and a great win for OSS!

Are they going to be opening a merge request to get their custom git command back in git proper then?

Re: We shrunk our Javascript monorepo git size

#86
post #2

> Large blobs happens when someone accidentally checks in some binary, so, not much you can do > Retroactively, once the file is there though, it's semi stuck in history. Arguably, the fix for that is to run filter-branch, remove the offending binary, teach and get everyone setup to use git-lfs for binaries, force push, and help everyone get their workstation to a good place. Far from ideal, but better than having a…

filter-repo is the recommended way these days:

https://github.com/newren/git-filter-repo

Re: We shrunk our Javascript monorepo git size

#87

Earlier quoted context omitted.

> 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. I read that as an anecdote, a more complete sentence would be "We had a story where someone from Europe couldn't clone the whole repo on his laptop for him to use on a journey across Europe because his disk is full at the time. He has since cleared up the disk and able to clone the repo". I don't think it…

The European Union doesn't like when a file get too big and powerful. It needs to be broken apart in order to give smaller files a chance of success.

Ever since they enshrined the Unix Philosophy into law, it's been touch-and-go for monorepotic corporations.

Re: We shrunk our Javascript monorepo git size

#88
post #82

Earlier quoted context omitted.

We were all impressed with google docs, but office.com is way more impressive. Collaborative editing between a web app, two mobile anpps and a desktop app with 30 years of backwards compatibility and it pretty much just works. No wonder that took a lot of JavaScript!

That's the thing, though, the compat story is terrible. I can't say much about the backwards one, but Microsoft has started the process of removing features from the native versions just to lower the bar for the web one catching up. Even my most Microsoft-enamoured colleagues are getting annoyed by this (and the state of all-MS things going downhill, but that's another story)

> That's the thing, though, the compat story is terrible.

It really is. With shared documents you just have to give up. If someone edits them on the web, in Teams, in the actual app or some other way like on iOS, it all goes to hell.

Pages get added or removed, images jump about, fonts change and various other horrors occur.

If you care, you’ll get ground into the earth.

Re: We shrunk our Javascript monorepo git size

#89
post #76
post #32

For those wondering where this new git-survey command is, it's actually not in git.git yet! The author is using microsoft's git fork, they've added this new command just this summer: https://github.com/microsoft/git/pull/667

[flagged]

Can you elaborate how exactly git is at risk here? These posts never do.

Re: We shrunk our Javascript monorepo git size

#90
post #76
post #32

For those wondering where this new git-survey command is, it's actually not in git.git yet! The author is using microsoft's git fork, they've added this new command just this summer: https://github.com/microsoft/git/pull/667

[flagged]

Oh for crying out loud.

"EEE" isn't a magic incantation, it's the name of an actual policy with actual tangible steps that their executives were implementing back when the CEO thought open source was the greatest threat to their business model.

Microsoft contributing to a project doesn't automatically make it EEE. For one thing, EEE was about adopting open standards in proprietary software. Microsoft during EEE didn't publish GPL code like this is.

Post reply on HN