Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We shrunk our Javascript monorepo git size

jonathancreamer.com

Post reply on HN
Print view View original

221–226 of 226 posts

Re: We shrunk our Javascript monorepo git size

#221

Post by js2 »

rurban wrote: post #213
js2 wrote: post #193

Earlier quoted context omitted.

> 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…

Sounds like it needs to be fixed to FNV1a

No, the problem isn't the hash. It does what it was designed to do. It's just that it was optimal for a particular use case that fits the Linux kernel better than Microsoft's use case. Switching the hash wouldn't improve either situation. If you want to understand this deeper, see the linked PRs.

Re: We shrunk our Javascript monorepo git size

#222

Post by [deleted] »

cocok wrote: post #86
fragmede wrote: 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

[deleted]

Re: We shrunk our Javascript monorepo git size

#223

Post by keybored »

deskr wrote: post #147
jakub_g wrote: post #67

Paraphrasing meat of the article: - When you have multiple files in the repo which have the same trailing 16 characters in the repo path, git may wrongly calculate deltas, mixing up between those files. In here they had multiple CHANGELOG.md files mixed up. - So if those files are big and change often, you end up with massive deltas and inflated repo size. - There's a new git option (in Microsoft git fork for now) an…

> in Microsoft git fork for now Wait, what? Has MS forked git?

Companies fork Git in order to work on things internally until they ready to be proposed for inclusion into Git itself. I’m pretty sure that GitHub and GitLab (and?) do the same thing.

These are not forks-going-their-own-way forks.

Re: We shrunk our Javascript monorepo git size

#224

Post by Dylan16807 »

dijit wrote: post #127
acdha wrote: post #126

Earlier quoted context omitted.

The extend phase starts when they make extensions which only work in their proprietary version. Putting extensive work into contributing them back is not the same.

Ok. There are a dozen examples of exactly this behaviour, and exactly this argumentation in response over the years. Right now the most important thing for them is for people to start thinking the microsoft fork is the superior one, even if things are “backported”.

If you cry foul every time microsoft Embraces something, you'll be proven right about EEE a lot of the time.

But you'll also be wrong a lot of the time.

This is not the Extend in EEE. We might get there, and we should be generally wary of microsoft, but this doesn't show that we're already there.

Re: We shrunk our Javascript monorepo git size

#225

Post by 0points »

ahoka wrote: post #115
0points wrote: post #57

Earlier 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?

Change landlord. I used to pay about 100 SEK for bahnhof in svenska bostäder before I moved away. It came with public IP and everything.

Re: We shrunk our Javascript monorepo git size

#226

Post by oftenwrong »

hinkley wrote: post #191
lopkeny12ko wrote: post #173

Earlier quoted context omitted.

This was exactly my first thought as well. This seems like an entirely self-manufactured problem.

When you have hundreds of developers you’re going to get millions of lines of code. Thats partly Parkinson’s Law but also we have not fully perfected the three way merge, encouraging devs spread out more than intrinsically necessary in order to avoid tripping over each other. If you really dig down into why we code the way we do, the “best practices” in software development, about half of them are heavily influenced…

This is one of the interesting benefits of https://www.unison-lang.org/ . A codebase of immutable functions inherently cannot have merge conflicts.
Post reply on HN