Jenniferplusplus
PSA: Do not put git repos inside other git repos. Git is not a package manager. You will make yourself sad. It doesn't matter how many conceptual primitives they share. Don't do it. Just use a package manager. You don't even need a package repository. You can still download things directly from git repos if you want to. Just list them in a package.json or something, and let npm do it. Or go.mod. Anything.
Please. For your own sake. And everyone who comes after you.
Jenniferplusplus
@foxxtrot all of the above. Subtrees, submodules, just git dirs inside other git dirs with no special handling. Also, honorable mention for references in the source to the repo's own history.
Jeff Craig
@jenniferplusplus Are you talking about git submodules (which no one, not even git developers, can make work), or someone actually committing a git repo inside a git repo (which is such a stupid thing to do that I can't imagine anyone doing it)?
groxx
@jenniferplusplus @malcircuit @frost I have the displeasure of watching a company move to a monorepo, struggle with education, and then create tons of engineers who can't figure out how to do anything in open source despite needing to understand and modify open source libraries they use on a pretty frequent basis.
So they just *don't*, mostly. They hit roadblocks, have zero tools or experience they can use, and often give up or ship it anyway and label it as a known issue.
:blobfoxnotlikethis:
Jenniferplusplus
@groxx @malcircuit @frost this is a really good point that I hadn't considered before
groxx
@jenniferplusplus @malcircuit @frost monorepos are also pretty much all (gigantic) snowflakes, so stuff you learn in one doesn't transfer to any other repo (whether it's a monorepo or anything else).
If you learn to use package managers like a normal person, that knowledge works everywhere, including open source.
Jenniferplusplus
@malcircuit @frost But even so, it's still better than nested git repos. Working with a monorepo is like climbing a gravel pile. Working with subtrees and/or submodules is like climbing a gravel pile filled with landmines.
Or we could just use package managers, which is like climbing stairs.
Jenniferplusplus
@malcircuit @frost google somewhat famously has a monorepo, and they insist it's the best thing ever and means they never have to spend any time or attention on updating dependencies.
They neglect to mention that they employ like 4,000 engineers whose only job is to build tooling to make it possible to work in the google monorepo.
Mallory's Musings & Mischief
Yeah, I was just reading up on it a bit, and now I understand why @jenniferplusplus is so opposed to them. It doesn't really fit with what I understand of the git ethos.
Martin Frost
@malcircuit @jenniferplusplus submodules are their own thing. They are a way to say that “my repo uses the code from this other repo”. I _think_ that’s not what Jenn is referring to, but to have actual git repos in a git repo.
Submodules are, in my opinion, a lot better, but they come with their own set of challenges.
A monorepo is where you put _all_ of your code, from all of your systems, into one repo. It tends to get messy, fast.
Mallory's Musings & Mischief
@jenniferplusplus So I'm familiar with git, but not using it to manage complex, large projects. I've only used it for solo and small team (less than a dozen people) projects, and I've never even heard of a 'monorepo'. Are git submodules related to all this stuff?
Jenniferplusplus
Monorepos are also bad, and you shouldn't do them, and they will make you and everyone who inherits that repo sad. Also angry. But it's still better than putting git repos inside other git repos. If you absolutely cannot manage your dependencies in a structured way, then just do a monorepo.
Please.
I am begging you.
Jenniferplusplus
Apparently the hardest problem in computer science is getting people not to put git repos inside other git repos.
Mallory's Musings & Mischief
@jenniferplusplus Yo dawg, I heard you like version control, so I put version control inside your version control so you can version control while you version control.
Moritz
@jenniferplusplus Can you confirm, that you’re not talking about submodules?
clacke
This is not a debate: hachyderm.io/@jenniferplusplus…
Yes, also submodules: hachyderm.io/@jenniferplusplus…
Roberto Piva
@jenniferplusplus can confirm. Have two project with submodules. Headache every time. Bonus: the artifacts are also linked in the package system, so you get entangled very fast.
Honestly it’s sad it has to be said but yeah, don’t push repos in repos.
FSMaxB
@jenniferplusplus and if you still want to do it, there's features to do it in a supported way. submodules is one option, subtrees are another.
Jenniferplusplus
@FSMaxB No, do not use subtrees. Do not use submodules. These are traps. Do not put git repos inside other git repos.
Tadeas Kriz
@jenniferplusplus do you consider git submodules or git subtrees a git repo inside other git repo (or both)?
clacke
Tadeas Kriz
@clacke Thanks! Missed that.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.