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

11–20 of 157 posts

Re: Debian Git Monorepo

#11

Post by baq »

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?

a hundred small repos are a different kind of nightmare.

the truth is, having a large code base is just hard no matter which way you handle it. you'll end up with custom repo tooling for the monorepo or blown up CI/CD infrastructure for many small repos either way. complexity will be conserved; it can be transferred, but can't be removed.

Re: Debian Git Monorepo

#12

Post by Muromec »

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?

Linux kernel is a monorepo and somehow works. On the other side of the spectrum we have leftpad nonsense and latest xz thing.

Re: Debian Git Monorepo

#13

Post by dijit »

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?

it requires a lot of discipline for sure.

"It depends" is thrown around a lot; what I've seen working for large companies and on large projects (mostly AAA games, which do use a monorepo typically) is that having a single repo means your dependencies are more likely to be vendored, and updating the vendoring re-runs all tests across all services because dependencies are mapped across the whole project.

Incremental build is also something that becomes more possible, rather than constantly building all source from scratch as we tend to do for smaller projects.

There's a lot to be said for atomic commits, no "merge trains"[0] and things like a "common library" (that everyone ends up building in a large enough team) are just includes and not entire dependencies with all that entails (versioning, updating dependencies etc;).

Having everything in one place also tends to force people to put documentation near their code instead of something else like confluence.

It's pros and cons, and the pro's are kind of meek-sounding until you've experienced it.

[0]: https://docs.gitlab.com/ee/ci/pipelines/merge_trains.html

Re: Debian Git Monorepo

#14

Post by frankjr »

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?

Having to switch branches in different repos to feature-xyz, remember to build it, and then finally work/test is more of a nightmare to me. In a monorepo, you just switch to the branch once, the build system builds everything that needs building, and you are ready to go.

Re: Debian Git Monorepo

#15

Post by xprn »

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’s what I understand from that side at least.

Re: Debian Git Monorepo

#16

Post by Cu3PO42 »

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 to our internal package registry and referenced it in the project. So far, so good. Turns out, feature X wasn't as well understood as we thought it was and we are still changing things around all the time. That meant: * changing the library * cutting a new release and publishing it * updating dependencies in the project and using the new feature

Since this was happening much too often for what was often a one or two line change, I moved the library into the project repo and build it as part of the project pipeline. This removes so much friction around these changes, I find it makes a significant difference. Eventually, I'll move the library back into its own repository, but for now the monorepo is the right choice in my eyes.

Re: Debian Git Monorepo

#17

Post by pheatherlite »

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?

Most developers jump on the hype train and don't stop to think about ramifications or requirements or purpose. Having said that, monorepos have their use cases, and they help eliminate the need to have convoluted tool chains whose entire purpose is to ensure version compatibility between various components of the system... before you can even start making a line of change on the dev machine.. or some asinine docker abstraction that you must spin up... essentially, if everything is in one place (and not conceived by antisocial pranksters), you bet it's meant to be together. This makes it easier for any number of different life cycle teams to pick up a project and not waste time chasing down silly time wasting issues.

Re: Debian Git Monorepo

#18

Post by Archelaos »

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…

> Turns out, feature X wasn't as well understood as we thought it was and we are still changing things around all the time.

If you publish something as a library for someone else, you should generally commit to supporting the public interface of that library as if it were a long-term support release. Exactly how long that should be depends on many factors, of course. But as a rule of thumb, I would recommend supporting this library version for at least two years. If that doesn't make sense, don't release it or look for a subset, where it makes sense.

Re: Debian Git Monorepo

#19

Post by ithkuil »

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 test your change (as opposed to waiting when integration happen later when dependencies between modules are bumped in a multi-repo)

Re: Debian Git Monorepo

#20

Post by rrr_oh_man »

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…

> Since this was happening much too often for what was often a one or two line change

The famous 5 minute project.

Happens in coding, car repair, and interstellar travel.

Post reply on HN