Just to jump in here, git submodules and similar are a terrible design pattern that needs killed, not expanded. Create a library properly and stop cutting corners that will bite you in the ass.
Three seperate companies wanting to do it the lazy, wrong way doesn’t suddenly make it a good idea.
Libraries are not always a suitable solution. You just haven’t worked on the same projects I have and you can’t imagine all the things submodules are used for.
On top of that, I can’t force all third party projects to turn their repos into nice easily installable packages. Especially if they’re using a language that doesn’t have a package manager.
I think the point the user was making is that, if it isn’t already distributed as a library, you can just fork it and deploy it as a library artifact to your company’s internal artifact repository. You shouldn’t be pulling an external project as a submodule, that’s just coupling yourself way way too tightly to external code. So you turn that code internal and into a library.
You shouldn’t be pulling an external project as a submodule, that’s just coupling yourself way way too tightly to external code.
You’re no more tightly coupled than if you zip that repo up, and put it on an internal server. It’s the exact same code you’ve just changed the distribution method.
And my whole point is that wouldn’t be necessary if Git had a version of submodules that worked properly!
I mean you are more tightly coupled. It’s way more likely that someone is going to pull the git submodule (especially if you’re doing this with multiple projects) than the someone updating the version of the library inadvertently. This applies even more if you’ve created the library and deployed it to your own artifactory yourself.
Just to jump in here, git submodules and similar are a terrible design pattern that needs killed, not expanded. Create a library properly and stop cutting corners that will bite you in the ass.
Three seperate companies wanting to do it the lazy, wrong way doesn’t suddenly make it a good idea.
Libraries are not always a suitable solution. You just haven’t worked on the same projects I have and you can’t imagine all the things submodules are used for.
On top of that, I can’t force all third party projects to turn their repos into nice easily installable packages. Especially if they’re using a language that doesn’t have a package manager.
I think the point the user was making is that, if it isn’t already distributed as a library, you can just fork it and deploy it as a library artifact to your company’s internal artifact repository. You shouldn’t be pulling an external project as a submodule, that’s just coupling yourself way way too tightly to external code. So you turn that code internal and into a library.
You’re no more tightly coupled than if you zip that repo up, and put it on an internal server. It’s the exact same code you’ve just changed the distribution method.
And my whole point is that wouldn’t be necessary if Git had a version of submodules that worked properly!
You guys seriously lack imagination.
I mean you are more tightly coupled. It’s way more likely that someone is going to pull the git submodule (especially if you’re doing this with multiple projects) than the someone updating the version of the library inadvertently. This applies even more if you’ve created the library and deployed it to your own artifactory yourself.
deleted by creator