That would be ok if git gave the option to track branches in subfolders and leave other branches alone. I had a look at submodules but I'm not clever enough to understand how it could help me.
Debian Git Monorepo
21–30 of 157 posts
Re: Debian Git Monorepo
#22I 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…
I don't think this is really advocacy for monorepo but rather advocacy against premature solidification of abstractions. Whenever I encounter a situation like this, the first step I take is to write the code without any API or interface boundaries to worry about. Then if I still feel it would be a good idea to separate it, I will separate it while keeping it in the source tree (this isn't really vendoring or monorepo, it's just abstraction into a module). Once this thing has survived a few rounds of revisions and you're ready to use it in another project, copy paste it first. Then once two projects have both had a chance to exercise the abstraction, then you factor it out into something totally separate
This process requires that you are able to work on rewrites and refactorings without having to beg. But it's truly the best way to get from an idea of a library to an actually well designed library.
In some situations it might be you already know what you want and can separate it out from the beginning, but if you are coming up with anything remotely novel, then you want to follow this process.
A monorepo will still contain libraries like these. It will also contain vendored code (although monorepos help reduce the amount of duplicate vendored bits of code). Making such changes will be easier in a monorepo once your abstraction starts to solidify. But the process you should go through should still be similar. The reason for not having two things depend on your wobbly abstraction too early is simply that it will inevitability lead to you prematurely solidifying uncertain abstractions.
Re: Debian Git Monorepo
#23I 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.
baq's law of code thermo dynamics: complexity cannot be removed. it can be transferred but can not be removed. your CI/CD system will be as complicated as your repo structure isn't.
Re: Debian Git Monorepo
#24Earlier quoted context omitted.
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 supporti…
This is exactly the friction/overhead the other person means and what monorepo works around.
(but also keep in mind this is an internal library for likely a couple of internal apps, supporting BC for 2 years is in most cases unwarranted)
Re: Debian Git Monorepo
#25I 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…
I find this too at work all the time. People are very quick to branch off some “independent” feature into its own service or lib and repo. Great for them when building, tiny repos do have that greenfield clean slate feeling, but awful when you realize the integration points aren’t as simple and well understood as they first thought.
Re: Debian Git Monorepo
#26I 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’…
they (well, Linus) invented git for their purposes, and not the other way around. They use git and mailing lists because that's how they work, and that's how they worked before git existed. git was built for them.
Re: Debian Git Monorepo
#27Earlier quoted context omitted.
> 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 supporti…
This is exactly the friction/overhead the other person means and what monorepo works around. (but also keep in mind this is an internal library for likely a couple of internal apps, supporting BC for 2 years is in most cases unwarranted)
Monorepo doesn't "work around" it, it means you have to support everything (including migrating/BC) on the current version, instead of having to support old stuff on the old version.
Re: Debian Git Monorepo
#28I 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…
That's not a monorepo.
Re: Debian Git Monorepo
#29Annoyed reading this one the 2nd but also a tad fooled because I thought of this in the context of a nuclear-option remedy to the XZ fiasco that's still lingering in all our heads.
Re: Debian Git Monorepo
#30I 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?
NixOS uses a monorepo and I think everyone loves it. I love being able to easily grep through all the packages source code, and there's regularly PRs that harmonizes conventions across many packages. Nixpkgs doesn't include the packaged software source code, so it's a lot more practical than what Debian is doing. Creating a whole distribution often requires changes synchronized across many packages, so it really make…
> Nixpkgs doesn't include the packaged software source code, so it's a lot more practical than what Debian is doing.
This is the key difference. OpenWRT is a “monorepo” too, but it downloads tar balls etc of the upstream software. Makes sense.
Putting the source code of the upstream software in a monorepo sounds like a nightmare…