4 ms·
> Oh, also Submodules suck like a supermassive, galaxy-core black hole. They suck like a chainsaw would sucks for cutting twigs. But they are very effective (t
by boris 6y ago
> Oh, also Submodules suck like a supermassive, galaxy-core black hole.
They suck like a chainsaw would sucks for cutting twigs. But they are very effective (together with symlinks) when you need to stitch an amalgamation of multiple repositories (which themselves could be stitched from multiple repositories). That's not to say you don't loose a finger or two now and again.
- ChrisMarshallNY 6y agoTrue, dat. I used them for this project: https://riftvalleysoftware.com/work/open-source-projects/#baobab https://riftvalleysoftware.com/work/open-source-projects/#ba... It's a long chain of submodules, and making tweaks to the lowest layer means a lot of pulls. I was able to semi-automate it with a couple of batch files. I didn't use Composer, because I figured that this was a project that would remain fairly static, and submodules are "native" (I am always a bit leery about depending on third-party package managers). Which has been the case, except that I'm writing an app that uses it as a backend, so I've had to make a few changes lately.
- user-the-name 6y agoNo, no, no. They just suck. It's not that the concept is bad - it is in fact very good, for the exact reason you suggest. They are just abysmally badly implemented. They barely work at all and frequently get your repo into nonsensical states for NO REASON other than that the tooling is utterly worthless. Mercurial has subrepos that offer conceptually the exact same functionality, but is actually implemented in a way that works WITH you rather than against you, and that will not constantly break. Git submodules are just a completely unfinished feature that is nearly unusable.