[stevefan1999]

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.

[kccqzy]

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.

[packetlost]

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.

[InitialLastName]

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

[gritzko]

In the Beagle SCM, I am doing my best to simplify that flow, but that is only doable because Beagle has multi-project repos. Still, there are some difficulties with submodule recursion. In the git model, difficult to imagine this working smoothly.

[1718627440]

You can combine the push step. A submodule intentionally follows a different development/commit/version cycle, otherwise you are supposed to use a subtree.

[a1o]

git submodule update —recursive —remote is that, isn’t? Perhaps throws also an —init if it’s the first time.

[Orphis]

To add to this, you can add in your .gitmodules the name of the branch that the --remote flag will follow. It just works.

[1718627440]

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.

[1718627440]

Submodules ARE multiple repositories. This is not an either or.

[kccqzy]

I understand that. I am just arguing that making your build tool aware of multiple repos is enough; no need to use submodules in git and make your build tool pretend to operate on a single repo.

[stackghost]

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.

[PaulDavisThe1st]

And a few of them think that it is corporate structure and development models that are actually the problem.

I'm just asking questions!

[stackghost]

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.

[PaulDavisThe1st]

No, I'm making the point that the way in which git doesn't fit well into many corporate processes can be interpreted as more of a negative commentary on those processes than on git.