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)

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?

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.

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.

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?

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

As a non-American, the dumbest change that affects me daily, is the renaming of the master branch. Master means teacher in romance languages and its variations are part of daily usage. In git there's no "slave" part so it always meant "main" and not "owner"

It affects me daily because "look on master" became "look on the main branch" for no advantage to absolutely anyone.

The strangest thing about the git branch controversy is that "master" was clearly used in a master/copy sense, just like you used to have a master music record that was then copied, but at the same time, basically every embedded communication protocol and many distributed computing systems still use terms like "bus master" and straight up "master-slave" configuration. Sure, for many protocols it's a very accurate description, but if we're going to try and remove such language from tech, why not start with the places where the words actually mean the same thing, not just happen to be homographs.

(I do support the master-main change in git for other reasons tho: it's much easier to translate and more natural to say. "Master record" is a term that never got translated into many languages, or at least not in a way that still makes sense for git)

I believe these sort of 'word bans' are motivated by Whorfianism; basically the idea that the sort of language we use can influence (or even set the bounds of) the kind of thoughts people have. But scientific evidence for Whorfianism is weak at best, and starts to seem particularly absurd when you try to state plainly exactly what you're trying to accomplish in situations like this. In this case, the idea seems to be that we can denormalize the practice of slavery by eliminating metaphorical references to slavery.

If you think about this, it's obviously a complete farce. The sort of people who engage in slavery today are not enabled to do so by such metaphors. And those apathetic to the problem of modern slavery, who might otherwise be doing something about it, were not made apathetic by the metaphors. The premise of fighting slavery by eliminating metaphors to slavery is pure pseudoscience of the highest order.

> why not start with the places where the words actually mean the same thing

If a word describes a bad thing, that's a reason to get rid of the bad thing. It's not a reason to ban the word.

Because the latter doesn't help anyone with real problems. Wow, we banished "master" from git. Did that make the world a better place for the people described in these articles (see links)?

https://www.hrw.org/reports/2004/saudi0704/4.htm

https://www.ilo.org/global/about-the-ilo/newsroom/news/WCMS_...

Did it positively impact any of these lives? Is it going to do so at any point in the future? If so, what specific outcomes can these people expect from it?

My point is, banishing words describing bad things, doesn't make the bad things go away.

Note how that sentence started with "but if we're going to try and remove such language from tech,". It wasn't a support of the idea, just of the execution. "If you're going to try and mug someone, why not do it somewhere with no CCTV?".

As for the reasoning, nobody thinks not having a "master" and "slave" chip in SPI is going to erase slavery and especially nobody (on the right side) is trying to erase the word altogether. The most common argument is that these terms should not be "watered down" by using them elsewhere - when you hear the word "slave", your immediate thought should be "human rights are being violated! who? where? how can we stop it?". It should bring up the thought of some of the worst human suffering in history, not some chips talking to each other.

(again, I'm not giving a judgement of the idea, just explaining the arguments for it the way I understand them)

I'm looking forward to the day physical mail is outlawed with few exceptions. Junk mail is such a wasteful endeavor only meant to subsidize shipments of value that can't be electronic.

I receive maybe 5 lb of paper mail a year, stuff which could be electronic.

I receive easily 500 lb of physical parcels a year, stuff like dog food, cat litter, coffee, etc.

Also, banning physical paper mail implies that you have to have an official email address for official documents like taxes.

> Also, banning physical paper mail implies that you have to have an official email address for official documents like taxes.

Or have a government online service where you receive such documents (as done here in Finland, though it is entirely optional).

European here: I do. I also have a federated government login that I can use to officially identify myself with the many government agencies.

I think browsers could nowadays figure out when enough bytes result in enough quality. Progressive images should have been the solution since the very beginning and it’s disappointing (yet expected) that they aren’t.

I really wish I could just point to the canonical source of an image and have the browser decide how much of is needed like it does for video segments.

Thumbnail: load 1000 bytes

Drag to desktop: download the remaining megabyte of your full-quality image

The current picture/sizes setup is a verbose joke hacked together because they refused to use progressive JPEGs for this purpose, which we had for a very long time. This whole thing could have been a single `<img progressive>` attribute

Browsers seemed to resist having a ton of in flight connections for a long time but I don’t know if that’s a problem with newer versions of HTTP including stream multiplexing. Though maybe it’s still not great for the server side?

Uhm, this is a preview. You’re not supposed to use it until it’s widely available. They’re just showing it off and gathering feedback.

> I'll file this under something interesting to revisit in a year or two.

Correct. However things are moving fast so certain new features become widely available within months.

> available within months.

Unless you need to support iOS... In which case, wait a few years because we can't have the web platform being too effective compared to apps...

They've been very quick at implementing CSS changes in Safari, faster than Firefox in some cases, but yeah bigger web APIs like push notifications have taken too long

Perhaps because CSS is entirely a programming task within the rendering engine...

But Web Push requires changes from the whole browser, perhaps minor changes to the OS, and probably a whole server side implementation.

And with all that cross-team effort going on, it's very easy for management to deprioritize it.

That seems like a good guess. I'd also guess that there are a lot more internal politics involved when they're implementing OS-integrated features that are easy to abuse. There are a lot of sites that ask for notification permission that definitely don't need to, and that probably saps some of the motivation for implementation at Apple. It's frustrating for developers with completely valid use cases, frustrating for open web standards, but I can understand being overprotective of user experience. It's a difficult balance.

So verbose. Better:

  document.querySelectorAll('*').forEach(element => element.animate(
    {translate: '5px 5px'},
    {duration: 500, iterations: 1/0}
  ))

Except that rude words weren’t taped over back then, unless you lived in a monastery.

I think you can ask that to ChatGPT in a follow up question ;)

You can always press “cmd minus” to bring the old web back. Every press brings you back by a decade

Same for my European bank. It’s annoying enough that I quit the app and reopen it to try FaceID again. I don’t even know my bank password