|
|
|
|
|
|
by zffr
1913 days ago
|
|
|
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 `pwd` is usually enough to know which repo I'm editing. (2) The author also says that committing changes with submodules can be confusing since it involves multiple commits: one commit in the submodule, and another in the main repo to update the commit it points to. I agree this is a little confusing at first and definitely tedious, but conceptually I think it is pretty simple. That said, I do agree that submodules are confusing -- just for different reasons. My main gripe with submodules are that they don't work well with the rest of git. Why isn't adding a submodule just a `git add` to a directory with a git repo inside of it? If there are new commits in a submodule, why doesn't `git checkout .` reset it back to the commit the main repo points to? If I clone a repo with submodules, why do I need to run additional submodule commands to get an exact copy of the codebase? Basically, to me it feels like submodules were slapped onto git as an afterthought and little care was taken to think the git CLI experience as a whole. I think submodules would be a lot less confusing if git had designed a better CLI for it. |
|
|
>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.