Thread

1. thunderfork · 1790875671 · focus · HN ↗

   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

   1. pixl97 · 1790875712 · focus · HN ↗

      Submodules are a mistake.

      1. mort96 · 1790875986 · focus · HN ↗

         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.

         1. bryanlarsen · 1790876368 · focus · HN ↗

            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.

            1. pavon · 1790876697 · focus · HN ↗

               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.
            2. mort96 · 1790876987 · focus · HN ↗

               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)?

               1. bryanlarsen · 1790877479 · focus · HN ↗

                  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.

                  1. mort96 · 1790877605 · focus · HN ↗

                     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.

Unofficial Hacker News client; not affiliated with Y Combinator.