I have no issue with rebasing on a local branch that no other repository knows about yet. I think that's great. As soon as the code leaves local though, things proceed at least to "exercise caution." If the branch is actively shared (like master, or a release branch if that's a thing, or a branch where people are collaborating), IMO rebasing is more of a footgun than it's worth.

You can mitigate that with good processes and well-informed engineers, but that's kinda true of all sorts of dubious ideas.

[–] expr 1 points 7 months ago (1 children)

Pushing to master in general is disabled by policy on the forge itself at every place I've worked. That's pretty standard practice. There's no good reason to leave the ability to push to master on.

There's no reason to avoid force pushing a rebased version of your local feature branch to the remote version of your feature branch, since no one else should be touching that branch. I literally do this at least once a day, sometimes more. It's a good practice that empowers you to craft a high-quality set of commits before merging into master. Doing this avoids the countless garbage fix typo commits (and spurious merge commits) that you'd have otherwise, making both reviews easier and giving you a higher-quality, more useful history after merge.

[–] [email protected] 1 points 6 months ago

Why should no one be touching it? You’re basically forcing manually communicated sync/check points on a system that was designed to ameliorate those bottlenecks