git submodules are such broken trash. The only reason we're even using them is to work around the Linux kernel setting EXTRAVERSION with git describe...
So ridiculously bad though. Is there at least a way of automatically dealing with a repo you cloned changing submodule URLs?
Conversation
Replying to
Be specific about what doesn't work for you. They work perfectly for me. I think a lot of senior developers have tunnel vision / fear around them. All the junior ones I know do great! Kind of weird actually.
RE: URLs, just edit .gitmodules and git commit -am =D
1
Replying to
The part that doesn't work is it will break for everyone else who has a clone of the repository. Also, it's not enough to edit .gitmodules. You need to also fix the remote in the nested repository. There's a git command to handle doing both instead of doing both manually.
1
That doesn't resolve that it breaks for everyone downstream though. It doesn't update the remote to the new one for them when they do `git submodule update --init --recursive`. How are they even supposed to deal with it beyond knowing what changed and fixing each repository?
1
It will try fetching a new revision from the old remote for them even though .gitmodules was updated because git doesn't actually bother syncing the nested repository to the new configuration. I don't see a way to do that automatically. I tried figuring it out.
1
They're honestly completely broken trash especially once you have them nested 3 levels deep. It's so incredibly hard to get it to the proper state without deleting the entire repository and starting over. It messed with rebasing, etc. massively too.
1
We had to fork github.com/GrapheneOS/ker this month which is a submodule of the kernel repository. It used to point at the AOSP repo since we don't make forks of repos we don't change. Every person who checked out submodules will now have their next submodule update break.
I genuinely have no clue what command they are supposed to run, if it even exists, beyond having them manually set the submodule origin remote to the new location with the appropriate command. Their .gitmodules is fine. It's the existing repo that's not. Even deinit isn't enough.
1
1

