Hacker News Reader

Comment by thunderfork | Hacker News Reader

A lot of replies here seem to be asserting that this "isn't that hard" without addressing the thing that makes it most hard: submodule compatibility and the breadth of tooling

View on HN

Submodules are a mistake.

They're the best way we have to reference other repositories from one repository. All other solutions don't have the benefit of being built in to git and having support built in to all git forges.

Ecosystems like Yocto are built around having meta layers as submodules. And, despite the usability flaws of submodules, it works really well.

I also use submodules to include dependencies into C++ projects a lot. It works fine.

git subtree and git subrepo are compatible with all git forges and don't require normal developers to install the extensions. Only the person/bot doing the occasional sync to the external repo has to install the extension. I prefer git subrepo for most (but not all) use cases.

Note that subtree and subrepo have the same SHA-1/SHA-256 incompatibility issue that submodules do, so this will be just as much of a trainwreck for them as well.

What's the advantage to using git subtree or git subrepo instead of git submodules? I've never heard of this, what's the difference between them? If it's an extension, how do people without the extensions end up downloading the code from the other repos?

How does it work with MRs, can I submit an MR which consists of changing the referenced SHA (and have it not show up as changes to every file in the referenced repo)?

They work by copying one repo inside another and providing tools to copy/sync it back out again. It's not a link, it's a copy. It's almost the same as copying the files into your repo and git add'ing them, but there are accounting and tools to pull changes from the subrepo back to the external repo.

The trade-offs are relatively obvious. It'd be a poor option for Yocto, but is a better option for most corporate repos.

Oh, I didn't want to vendor another repo into mine, I just want to store a reference to it. I'll keep using submodules then, as they're easier to work with than tools like gclient and repo.

I really don't get the hate. They're not hard to work with. Just a bit shitty UX but if you're using Git you're used to that already.

I won't defend submodules, but I also don't accept this as a response because it's irrelevant. They are used and it will be an unbearable pain when they break.

> Submodules are a mistake.

Someone started this FUD a long time ago and it has worked. Instead of using an elegant mechanism, project have built inelegant wrappers on top of git like go.mod which are actual mistakes.

It is the same people who say Git is unseasonably hard to learn. It isn't. Git and its command line is ugly and hard to remember. Understanding what those commands do at a commit and a branch level isn't really difficult. Even the internal object model is only moderately difficult.

I say this as a person who strongly dislikes many many aspects of Unix and Linux due to bad design and terrible UX. Git has a better design than any Unix program you get.

Submodules work okay. It is just Git LFS but for Git repos. Get over it.

I’m not the author but I agree with their opinion.

Compare the UX of go mod with git submodules. One is easy and the other is about as fun as having teeth extracted.

git’s UX has never been its strong point. But submodules takes that pain to a whole new level.

I find them extremely useful. It gives me a monorepo experience in repos that otherwise aren't/can't exist as one monorepo for various reasons.

Reply on news.ycombinator.com