5 ms·
You're using them wrong. I've been using them for years and I have no issues with them, however I treat them as a read-only dependency. They have their use and
by pancrufty 4y ago
You're using them wrong. I've been using them for years and I have no issues with them, however I treat them as a read-only dependency.
They have their use and it's not that hard once you figure out the exact sequence of git commands to use (but that applies to all of git)
- 0xy 4y agoThe fact some developers hate them is reason alone to never use them. Using them means you don't care about developer productivity. You will incur thousands or tens of thousands of dollars in additional costs by using submodules, via wasted developer time.
- cupachabra 4y agoHow would you quantify impact of something like that? Using a tool like Jellyfish, linearB, Adadot etc or just hope people would see enough difference to justify investment?
- isaacremuant 4y agoYou can make that incredibly reductive argument about anything. Even unit tests. If the tool is right, you generate buy-in. If you don't, then either it isn't that good or you're not good at generating buy-in.
- eru 4y agoYes. And buy-in doesn't necessarily mean that people will love the chosen tool. Just that they understand and accept the compromises made.
- mcny 4y ago> Yes. And buy-in doesn't necessarily mean that people will love the chosen tool. Just that they understand and accept the compromises made. I think we are saying the same thing in different words. I don't hate most things. I don't have an opinion on most things. I am pretty indifferent about those things. I don't hate git submodules. However, I think we should at least hear out the concerns of people who hate git submodules. If you still want to use git submodules, then at least you've made an educated decision.
- eru 4y agoI'm not sure. Going by that reasoning, you couldn't use anything at all ever. Really silly example: not indenting your code is universally seen as bad. But there are both people hating tabs, and there are people hating spaces.
- nly 4y agoDevelopers time isnt that valuable. It's a nice myth, but it isn't.
- chongli 4y agoBy read-only dependency do you mean that you’re not a developer for those repositories? What if you do develop a library and then want to use it in an application?
- rusticpenn 4y agoI consider microservices and submodules to be mainly a solution to organizational problems.
- oleganza 4y agoWhat is being meant (i presume) is that even if you are a developer of those repos, do not edit them within the host repo. Work on them separately, as if you were an independent developer, and then bump their revision as a submodule - the same you do with bumping a dependency version in your Makefile/package.json etc.
- worksonmine 4y agoI assume read-only from the perspective of the dependent. Any fixes belong in the modules upstream repository, then pulled in to the dependent once pushed.
- frizlab 4y agoSame here. I’ve used them a lot. Yes they’re not trivial and feel half-baked, but used correctly they do work. Anyway, any git article saying “throwing everything away is the only way to recover” I know it’s not a good article…
- globular-toast 4y agoIt is a great way to tell if someone knows what they're doing with git. Even joking about deleting the repository and recloning is enough to let me know. Unfortunately this includes 99% of people I've ever worked with.
- fanf2 4y agoI had awful problems with git submodules in the Ansible repo. When I wanted to change branch, I couldn’t use `git checkout` as usual: I had to blow away the submodules, switch branch, then reinitialize them again. Appalling failure to leave submodules so unfinished that branching doesn’t work properly any more.
- michaelmior 4y agoI haven't had a problem in general with switching branches and submodules. You just change branches and then `git submodule update`. Or `git checkout --recurse-submodules`. You can also set this as the default behavior so that checkout automatically updates submodules. `git config --global submodule.recurse true`
- fanf2 4y agoI think the worst problems happened when switching between branches where the same directory changed between being a submodule or being part of the parent repo. Having to set a configuration option to make submodules work is another example of the feature being unfinished.
- michaelmior 4y agoThey work just fine without that option. But I can see why having that as a default might be a better choice.
- baby 4y agoI had that command set previously, and OMG it made every checkout slow as hell! There's like a dozen submodules in the repo I work in, it's a nightmare.
- usr1106 4y agoHaving had no issues with them sounds unreal. Everyone has to learn what they can do and what to avoid. We use the to build our whole system out of one commit, although we have several repos. We made the artificial rule that a commit that updates a submodule must not contain any other changes. It has reduced the number of problems especially related to rebasing.
- pancrufty 4y agoI had no issues that were directly attributable to the way they behave and not to my own ignorance. In short: once I learned and documented the checkout/update/reset commands, I was set. The other “issues” were that they require extra config in some cases (CI), but again it’s just 2 lines in most cases.
- baby 4y agoI don't trust GP, I deal with them every day and they are a nuisance every day. Perhaps they are not working in these submodules and just set them to a hash once and never had to make changes there. Then sure, but as soon as you're working actively in these submodules it's mayhem.
- baby 4y agofor read-only dependencies why not just vendor the dependency then? Or better, use a package manager at this point.