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
By the way, the Linux kernel doing that is extremely annoying because it means your repository ends up with non-reproducible builds after you add tags.
Our standard approach is building a release, testing it, then tagging the release. We had to change their script for this.
1
3
Not going to rebuild the kernel and then the OS build in order to get it to use a tag. We changed it to always use the kernel.org kernel version with EXTRAVERSION using the git revision rather than trying to opportunistically base the version on the tags.
1
4
Replying to
That's misleading since it's not simply the kernel.org version and we don't really want an incorrect version set. Using the Git revision is perfect but that breaks if we use repo rather than submodules since it considers the repository dirty, as it should be doing.
1
We don't really hate the concept of doing this, at least as long as it doesn't use tags. The issue is that submodules are so poorly designed/implemented that they're legitimately a completely broken feature.
Maybe it would work better if we used sub-trees. Have not had much experience dealing with them especially in a repository like this where we maintain a rebased patchset for each forked repository and we're adding the submodules (or sub-trees) as part of the patch set.
1
Have a feeling that it's too opinionated/rigid to fit into what we need. Submodules mostly work but it's a completely broken feature, honestly.
1
Show replies