51–60 of 73 posts
I don't see the point of submodules. If you want to make a change in another repo, do that. If you want to reference a specific version of another package in your code, do that. When would I want submodules?
When you have library that is useful to more than one project, but not popular enough to have its own package on multiple package managers. Then the easiest way to reference a specific version of the library is to submodule it.
I've been the git fixer for a few different teams. I want to like submodules, but there's something that doesn't fit my brain the way the rest of git does. It feels half-baked. I think we're still missing the best way to model the problem as a tree of related states.
I dislike having to warn in the README file, "somewhere in this repo are submodules, and you need to use this incantation to clone them."
I think you can now have the submodule reference point to a branch but it can't point to a tag, which is what I want most of the time.
And there's how `git status` just reports "modified content" without going into details.
What do people think of git subtrees? https://codewinsarguments.co/2016/05/01/git-submodules-vs-gi... Or the non-standard git-subrepo? https://github.com/ingydotnet/git-subrepo
I don't see the point of submodules. If you want to make a change in another repo, do that. If you want to reference a specific version of another package in your code, do that. When would I want submodules?
In the first[1], it's to include the project's JS implementation in the project's website. Considering that this would be the only JS code running on the entire site, it seemed like overkill to throw in some newfangled asset manager like Bower just for a single NPM package.
In the second[2], it's to include the encoding/decoding test cases alongside the implementations. This way, instead of having to maintain a bunch of independent per-implementation unit tests, I can maintain all the tests in one place, and then have the per-implementation test suites snarf the test cases, and I then know with reasonable certainty that all my implementation libraries have equivalent behavior.
There are probably other, "better" ways to do both these things - I could bite the bullet and use Bower for the website, and I could have test suites download test cases on-the-fly - but submodules were the path of least resistance, and I've yet to encounter any significant downsides.
----
[0]: https://base32h.github.io
[1]: https://github.com/Base32H/base32h.github.io - specifically /assets/base32h/, which points to https://github.com/Base32H/base32h.js
[2]: https://github.com/Base32H/base32h.rb - specifically /spec/cases, which points to https://github.com/Base32H/base32h-tests
Clickbait title. The author literally says "Spoiler alert. I do not hate submodules." and also later recommends submodules for language ecosystems that don't have built-in package managers. The author also gives (IMO) 2 weak reasons against submodules. (1) He says its hard to know which repo you're editing (main repo or submodule). I agree, but in practice this hasn't been an issue for me. A simple `git status` or `p…
For any project where I could choose not to use them, I choose not to use them.
I routinely encounter problems where the file structure on disk gets out of sync with the .gitmodules file, or one of the internal files inside .git, and I need to completely recreate my local repo. I dislike having to warn in the README file, "somewhere in this repo are submodules, and you need to use this incantation to clone them." I think you can now have the submodule reference point to a branch but it can't poi…
The "correct" (albeit still annoying) way:
- git submodule deinit
- rm -f
- git submodule add ... new/path
In an emergency situation, you can almost always recover. I've not corrupted a repo in almost 10 years and I do some unspeakable things to them :)
To remove a module manually:
- git reset . (from root; NOT --hard)
- Remove the from working directory.
- Remove entry from .gitmodules
- Remove entry from .git/config
- Remove (-rf) the folder .git/module/ directory (it follows the same structure as the working directory)
- git add -A .gitmodules (Tab completion might not work but the command will)
This can be used to forcefully remove a submodule.
To remove all submodules without starting over (I've personally never needed this in the last X years):
- Remove all working directory paths for each submodule
- Remove .gitmodules
- Remove .git/modules/
- Remove any mention of submodules in .git/config
- git add -A
Usually the first manual one solves whatever problem you're facing.
EDIT: I have no idea how to format HN comments, sorry :| nothing I try works. Hope it's readable.
I used to have a bunch of hacky scripts for working around this, but lately I've just been giving up and avoiding submodules as much as possible.
I also hate monorepos. I consider the monorepo to be an anti-pattern. It's an architectural advantage to separate each module into a different repo as it encourages careful separation of concerns. If you find that you often need to update many modules together every time you want to add a new feature to your project, this is often an indication that your modules do not have proper separation of concerns and your abst…
- in 2 repos -> 2 PRs -> 2 test suites -> 2 code reviews
- in a monorepo -> 1 PR -> 1 test suite -> 1 code review
Having a monorepo helps.
Consider having all your docker images and helm charts alongside the source code of the many parts of your big project. Is that really an anti-pattern?
EDIT: also a new dev arriving in the team, having to clone only one repository is easier for them. I also try to have a simple docker-compose stack so they have only one command to spin up the whole dev environment.
Clickbait title. The author literally says "Spoiler alert. I do not hate submodules." and also later recommends submodules for language ecosystems that don't have built-in package managers. The author also gives (IMO) 2 weak reasons against submodules. (1) He says its hard to know which repo you're editing (main repo or submodule). I agree, but in practice this hasn't been an issue for me. A simple `git status` or `p…
>If I clone a repo with submodules, why do I need to run additional submodule commands to get an exact copy of the codebase?
`git config [--global] submodule.recurse true` resolves both questions.
As to why is that not the default? I _believe_ there are security concerns, but I'm not 100% sure.