Comment by stevefan1999
8 hours ago
That's by design of git, you can't forget that git is first developed for a bazaar model of information flow, especially with a big decentrailized project like the Linux Kernel, not the silo and isolated corporate NDA and closed model you described. Git prefers open information and discourages information closures and segregation of information by placing restrictions exactly like this.
Git enthusiast would often tell you to do this separately with a submodule, and set permission on the version control forge software level (which means Gitea/Github private RBAC access to certain repos for cloning), sure, but that is also painful as hell.
But my point is that all of this is exactly by design from Linus Torvalds's need for Linux Kernel to replace BitKeeper. Git simply isn't the tool for everything, it was developed for a software project with liberalism in mind, but corporate stuff is monoculture and prefers proprietary, shut-in model, and the eat your own dog food mindset, and no wonder it is so painful to deal with.
Git submodules aren’t convenient either. For the silo and corporate development use case, just use multiple repositories and make your build tool aware of multiple repositories. It is slightly less painful than submodules.
I feel like submodules could be a lot easier to work with if the git command made it easy to update all submodules in one go based on branch head for the submodule.
That and a way to recursively commit/push (i.e. make a change within a submodule, commit in one step with the same message in the parent submodule).
Right now, if you want to push a change to a file in a submodule such that it propagates to the users of your repo, you have to:
1. Change the file
2. Commit within the submodule
3. Push the submodule
4. add the submodule change in the outer repo
5. commit in the outer repo
6. push the outer repo
1 reply →
You can set submodule.recurse to true and then git commands operate as if you passed --recurse to them? It's just that most people don't actually want that, because a submodule is generally something you intentionally want to handle separate.
git submodule update —recursive —remote is that, isn’t? Perhaps throws also an —init if it’s the first time.
2 replies →
Submodules ARE multiple repositories. This is not an either or.
I think everyone knows that this is a consequence of git's design. Nobody's disputing that.
Unfortunately there are many people who think git is a panacea and is suitable for all version control tasks of anything.
And a few of them think that it is corporate structure and development models that are actually the problem.
I'm just asking questions!
I don't understand what you're trying to imply.
If you're making the point that there are multiple confounding factors to just about any non-trivial problem, then I agree.
1 reply →