It's getting to be like sunglasses, where you get your choice of branding and labels but it all costs too much and comes from the same place. These days I just stick to the cheap yellow stuff that comes in big cans.
Hmm, usually when I hear people talk about growth mindset, it’s not about ability vs effort. Rather it’s about the tendency to accept things as they are and try to work within those parameters, vs changing the parameters.
The stuff about “lying” should be disregarded. Using rebase or merge is not a moral issue. Well, it would be bad to rebase master or some other public branch, so don’t do that. Not because it’s lying but because it will cause problems and confusion. Screw it up bad enough and you’ll lose data.
The chain of broken commits is unfortunate, but add a bug fix commit and then rebase to squash it into whatever commit it belongs. The problem is the assumption in the feature branch that the dependency is still there when it isn’t. The problem is not rebase. The fix for the missing dependency has to happen somehow, squashing in a bugfix is a fine way to handle it.
When conflicts are introduced, I’ll agree that rebasing becomes a lot more painful and less useful. Rebasing through the constant stream of conflicts is maddening. It’s not clear what to do here, but repeatedly merging brings all sorts of ugly pain with it, like the fact that your branch ends up littered with changes that you didn’t make and are unrelated to the actual purpose of the branch.
I’ll close by saying that if you work in a fast-moving monorepo, rebasing becomes a more pressing concern.