Hacker News Reader

Comment by pancrufty | Hacker News Reader

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)

View on HN

Same 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…

It 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.

I 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.

I 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`

I 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.

They work just fine without that option. But I can see why having that as a default might be a better choice.

I 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.

By 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?

I consider microservices and submodules to be mainly a solution to organizational problems.

What 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.

I 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.

Having 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.

I 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.

I 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.

for read-only dependencies why not just vendor the dependency then? Or better, use a package manager at this point.

The 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.

You 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.

Yes. And buy-in doesn't necessarily mean that people will love the chosen tool. Just that they understand and accept the compromises made.

> 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.

I'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.

Developers time isnt that valuable. It's a nice myth, but it isn't.

How 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?

Reply on news.ycombinator.com