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

Debian Git Monorepo

blog.liw.fi

Post reply on HN
Print view View original

51–60 of 157 posts

Re: Debian Git Monorepo

#51

Post by 4ad »

dijit wrote: post #2

I was always surprised that Perforce didn't have anything for open source, Git is basically eating their lunch because monorepo's suck so much with git; so people do things in a more fragmented and git-friendly way. Not that I really want to see a proprietary product succeed, but it's somewhat surprising that: A) We don't have anything better B) Perforce isn't trying to gain adoption by giving its software for free t…

> Perforce isn't trying to gain adoption by giving its software for free to distro maintainers

Perforce has been giving its software for free to OSS projects since forever. FreeBSD used to use Perforce, for example.

OSS people and projects don't want Perforce, not the other way around.

Re: Debian Git Monorepo

#52

Post by jorvi »

xprn wrote: post #15
dijit wrote: post #2

I was always surprised that Perforce didn't have anything for open source, Git is basically eating their lunch because monorepo's suck so much with git; so people do things in a more fragmented and git-friendly way. Not that I really want to see a proprietary product succeed, but it's somewhat surprising that: A) We don't have anything better B) Perforce isn't trying to gain adoption by giving its software for free t…

I would actually think that monorepos suck with Github and others like that. Looking at the Linux kernel for example, that seems to me like a well executed monorepo outside of Github. From what I’ve heard and read, they specifically use Git and mailing lists instead of Github or others because Github wouldn’t work for what Linux is (aside from as a mirror). There might very well be some context I’m missing, but that’…

Github / Gitlab would work great and reduce friction for kernel contribution. The refusal to switch or provide the alternate path is mostly inertia.

Re: Debian Git Monorepo

#53

Post by IshKebab »

ithkuil wrote: post #19
G3rn0ti wrote: post #7

I know it‘s an April‘s fool. But I don’t get this recent trend of people arguing in favor of a monorepo (at my work place, too). It’s a nightmare to handle and use. What gives?

The opensource tooling to handle large monorepos is just not there. The monorepo at Google with the massively distributed build system and all other tooling make it very effective to work with. You cannot just take one part of that system and expect to magically reap the benefits. The main benefit I see in practice is that you can immediately see which parts of the system are broken by your change immediately as you…

I agree it's definitely an underserved tooling area. But so is a maze of submodules which is the realistic alternative. Open source just doesn't care too much about whole-company level projects because those don't really exist in the open source world.

That said, you can definitely make it work with Git & Bazel. Beats submodules by a mile.

Re: Debian Git Monorepo

#54

Post by bluGill »

4ad wrote: post #51
dijit wrote: post #2

I was always surprised that Perforce didn't have anything for open source, Git is basically eating their lunch because monorepo's suck so much with git; so people do things in a more fragmented and git-friendly way. Not that I really want to see a proprietary product succeed, but it's somewhat surprising that: A) We don't have anything better B) Perforce isn't trying to gain adoption by giving its software for free t…

> Perforce isn't trying to gain adoption by giving its software for free to distro maintainers Perforce has been giving its software for free to OSS projects since forever. FreeBSD used to use Perforce, for example. OSS people and projects don't want Perforce, not the other way around.

Freebsd developers used perforce but the official repo was cvs and somehow the two synced.

Re: Debian Git Monorepo

#55

Post by hk__2 »

Cu3PO42 wrote: post #16
G3rn0ti wrote: post #7

I know it‘s an April‘s fool. But I don’t get this recent trend of people arguing in favor of a monorepo (at my work place, too). It’s a nightmare to handle and use. What gives?

There are real, tangible benefits to monorepos. And real, tangible downsides, too. Like everything else, it's a tradeoff. I'm sure people advocating for them have brought up some benefits. But in case they haven't, here's an example I recently encountered at work: for an application we are developing, we needed functionality X. We knew that we'd need X in other projects, too, so we made it a library. I published it t…

> for an application we are developing, we needed functionality X. We knew that we'd need X in other projects, too, so we made it a library

This is the mistake: you should make it a library when you do need the functionality, not when you "know" you "would need" it.

Re: Debian Git Monorepo

#56

Post by IshKebab »

surajrmal wrote: post #37
G3rn0ti wrote: post #7

I know it‘s an April‘s fool. But I don’t get this recent trend of people arguing in favor of a monorepo (at my work place, too). It’s a nightmare to handle and use. What gives?

I struggle to understand the upside of avoiding monorepos. A lot of people think it means you can't decouple releases, modularize builds and similar with a monorepo, but that's simply not true. The efficiency at which you can refactor and upgrade your codebase cannot be understated.

The main upsides I see are:

* you can pretend you don't need a proper sandboxing build system like Bazel, Buck etc. and stick to Make/CMake etc.

* you don't need to learn how to use sparse checkouts

It basically lets you avoid learning how to solve the problems you'll inevitably run into for a little while. Not a great reason, but it is a reason.

Re: Debian Git Monorepo

#57

Post by necrobrit »

ithkuil wrote: post #19
G3rn0ti wrote: post #7

I know it‘s an April‘s fool. But I don’t get this recent trend of people arguing in favor of a monorepo (at my work place, too). It’s a nightmare to handle and use. What gives?

The opensource tooling to handle large monorepos is just not there. The monorepo at Google with the massively distributed build system and all other tooling make it very effective to work with. You cannot just take one part of that system and expect to magically reap the benefits. The main benefit I see in practice is that you can immediately see which parts of the system are broken by your change immediately as you…

>You cannot just take one part of that system and expect to magically reap the benefits.

Yeah, specifically people only focus on the "repo" bit. Build system, PRs, history browsing, etc all get handwaved away after you stick all the code in a single repo. These are the extra hard parts though!

I think if you were to properly implement "monorepos" in git world it would actually look a lot like a Github _organisation_, rather than a Github repository. Each git "repo" in the "org" would be a workspace with it's own segregated UI so that you can for example check out just that workspace, or see only that workspaces commits or issues -- but some features such as github actions workflow triggers and PRs would be able to span multiple workspaces.

Github doesn't really seem to have put much thought into really supporting monorepos though. They have added some support (e.g. codeowners) to support "repo"-as-monorepo, but have also added some features that could go towards supporting "org"-as-monorepo (e.g. dependabot dependency updates and the dependency graph). But it all stops well short of a complete monorepo toolset.

Re: Debian Git Monorepo

#58

Post by alkonaut »

I didn't lift an eyebrow at the headline which is apparently an april fools joke.

But what is it that makes it so absurd that it works as a joke, which I'm missing? The size seems absurd (500GB) but why would the Debian source be 500GB?

To me it's in no way obvious that "Debian" would include any third party packages repackaged by the distro maintainers. Are Debian people maintaining N source repositories for third party code today, which would be the code merged into this hypothetical monorepo? Why?

Re: Debian Git Monorepo

#59

Post by mewpmewp2 »

Archelaos wrote: post #39
surajrmal wrote: post #32

Earlier quoted context omitted.

This guidance is far too specific to make sense in the general case. Not every scenario has the same constraints. If I had to pay a 2 year maintenance cost for every library I write and wanted to reuse between projects I'd never end up writing it. If you can migrate all library clients over to the new version, there is no reason to maintain old versions.

I would not call this a "library", but a set of interrelated project with "shared moduls" instead. With a "library" I mean a piece of code where the publisher does know who is using it for what exact purpose. Of couse we could now fight over a proper general definition for "library", but this is how I would use the term in this context, because thee long term aspect is what really makes outsourcing such code meaningf…

The argument then is also that monorepo allows you to use this as "shared modules" instead of published "libraries".

The point is you have some code that you want to reuse, and either within a monorepo or between multiple repositories.

Re: Debian Git Monorepo

#60

Post by richardwhiuk »

alkonaut wrote: post #58

I didn't lift an eyebrow at the headline which is apparently an april fools joke. But what is it that makes it so absurd that it works as a joke, which I'm missing? The size seems absurd (500GB) but why would the Debian source be 500GB? To me it's in no way obvious that "Debian" would include any third party packages repackaged by the distro maintainers. Are Debian people maintaining N source repositories for third p…

Debian does include the third party packages. This is either a mirror of the git repository, or a tarball of the upstream code.
Post reply on HN