7 ms·

I don't understand all the negativity in this thread. Submodules can be annoying in that they require special attention and treatment all the time. You need to

• 60secz 4y ago
  > Submodules are usually good for frameworks and libraries that are more stable than your main codebase. However, those submodules under active development within the same organizations can be a pain to maintain. Except they aren't. Libraries are better in their own code base and published as a separate artifact which is auto-versioned.
  • 60secz 4y ago
    https://abildskov.io/2021/03/28/why-i-hate-submodules/ https://abildskov.io/2021/03/28/why-i-hate-submodules/
  • _gabe_ 4y ago
    From the article you linked: > I know some programming ecosystems, such as C++ does not have a default way of handling libraries and dependencies, and in that case it might be good to look into submodules. > Please, if there is any dependency management in your chosen platform use it. I use C++. There is no such thing as package management in C++ (at least no unified standard that you can use with confidence with every library). So giving a blanket statement and saying that you should just ship library artifacts is a non starter in a language like C++. This basically implies either creating a package manager, or distributing binaries manually, or forcing users to find the correct versions manually and install them. Git submodules is extremely helpful here, and if you look at the documentation this is what it sounds like it was created for: > Large projects are often composed of smaller, self-contained modules. For example, an embedded Linux distribution’s source tree would include every piece of software in the distribution with some local modifications; a movie player might need to build against a specific, known-working version of a decompression library; several independent programs might all share the same build scripts.[0] If this suggestion here doesn't sound like your use case, then your probably using the wrong tool. In the same way, you wouldn't tell people who use a hammer to cut a piece of wood in half that the hammer must be a terrible tool. You would say something like, you're using the wrong tool, here's a saw. Use the correct tool for the job at hand. If you need source code from a 3rd party library that you won't modify but you depend on, a submodule is a fine tool for the job. [0]: https://git-scm.com/docs/user-manual#submodules https://git-scm.com/docs/user-manual#submodules
• saxonww 4y ago
  This 'solves' the submodule problem by just copying everything, as far as I can tell. A few big differences from submodules: With X-modules, you have all the code in your repo, vs. a reference to the other repo. If you are looking at submodules to manage repo size, this solution is not for you. With X-modules, you are tracking a branch, not a revision. If you want to pin an external dependency, it's not clear that you can do that with an X-module (the screencast doesn't show it, I don't think). X-modules require an extra application to manage the repo relationships. There's a command-line client, but it's listed as unsupported on their website. It's not clear what the auth story is around who can make these changes. It doesn't look like adding an X-module would be subject to code review. Personally, I'm not interested in this at all. I don't think it's a bad product, but I wonder what problems it actually solves. I don't know how common the submodule pattern is to compose a monorepo like they've demonstrated, not in an 'enterprise' setting they hint at future pricing for, anyway. And it's not clear to me whether their sync pattern is going to be OK for external third-party dependencies, unless you want to actually track their changes automatically vs. being intentional about when you pull in changes; this seems like a supply chain issue to me.
  • oka 4y ago
    With x-modules we aim to solve the issues that monorepo introduces keeping the benefits. Benefits: easy cross-component changes, repeatable builds Issues: huge repositories, lack of code ownership boundaries, complicated versioning for individual products/components Of course people nowadays rarely use submodules to build a monorepo, but I believe they would like to if submodules would be transparent. Git X-modules are at early stage and only syncs a ref with a directory now. We'll add an option to pin a particular commit and most interesting - an option to receive module changes as PRs queue that could be individually accepted (and applied alongside with the necessary call site refactorings). Git X-modules is available for GitHub users now, and we plan to add GitLab and Bitbucket support - both cloud and on-premises. So, we reuse platform's user management to only let repository admins/devs set up the modules - currently via web UI, and via .xmodules files in the future versions.
• mathstuf 4y ago
  I don't like them either, but things are a lot more manageable if: - you require that the submodule always move forward (reverts are not allowed; you must fix the submodule and get something there first) - the submodule commit must always be reachable from the configured branch (`submodule.NAME.branch` in `.gitmodules`) - you require that commit be in the first parent history of the branch This makes conflict resolution trivial (the last prevents MR heads conflicting because the first-parent history linearizes and requires that "A contains B" be true in one pairing). Without these requirements, it is really a wild west of insanity IME. Much better just to use the dependency mechanisms of whatever tools you use (assuming they exist).