Post #362266

@glyph@mastodon.social @mcc@mastodon.social @whitequark@social.treehouse.systems I have found that there are actually some options that help here! submodule.recurse true This makes many of the pull/checkout/etc operations do what you mean recursively including submodules. You still need to do something to initially pull the submodules, this doesn't change the fact that submodule are something you need to opt into, and of course any commits you still need to deal with committing and pushing in the submodule before the parent, but it means that if you just want "when I checkout a new branch, also checkout the appropriate submodule commit for that branch" just work. status.submoduleSummary true diff.submodule log These options provide better status information, so when you have some change in the submodule compared to what commit you're on, you can see what commits added/removed there are in the submodule, rather than just a couple of SHA identifiers. These dramatically improve the UX of working with submodules. I still find that people reach for them too much, but they're more tolerable with these options. Not sure why they aren't on by default.