I wrote a blog post on why I use #git #submodules despite the fact that they're awful :)
As I say in the article I welcome ideas on how to do this differently. My implentation isn't perfect but it does what I need for now!
https://www.feoh.org/posts/git-submodules-are-awful-but-occasionally-necessary
@feoh I'm curious if you've experimented with git subtrees, which I've heard solve most of the problems with submodules.
@spacehobo @varx Yeah, Perforce is inferior to Git in a lot of ways but one thing it REALLY did well IMO is having the notion of 'client' which could map any number of disparate repository paths into your workspace in an arbitrarily laid out way.
But even *THAT* doesn't address the problem of wanting to integrate whole other repositories!
It's worth noting that this is tricky stuff to get right, and I applaud Git even trying honestly :)
@spacehobo @varx I'm very lucky in that my use case is SO simple:
I have ONE submodule for my Neovim dotfiles project fork. That's it, and when it updates? I'm the one doing the updating! So drift isn't an issue :)
The only issue here is the inherent jank submodules bring to the table. I look forward to seeing if subtrees reduce the jank severity :)
@varx OOH I haven't! Thank you for that! I will indeed have a play with them this evening.
@feoh I'll be curious to hear about your experiences if you do.
I've been thinking of trying them out at work -- we have a *lot* of repositories, and all of them have some boilerplate stuff that tends of diverge over time as people make changes. (And they diverge from the new-repo template, and changes to the template don't get applied to the existing repos.) I'm thinking maybe we can use subtrees to make updates and diffs a little easier... but I haven't trialed it yet!
@varx Hey thanks again for this! I just implemented it in my configuration and it's positively RAD :) No more faffing with ~/.gitmodules!