[fulafel]

But you can't safely rebase that branch! Having rebased it, you would have now broken it for others working on it. So this is a great example how the damage spreads and taints other branches around the history rewrite.

(And even arriving at the "ok i could fix this with rebase" diagnosis will have been painful and frustrating and eaten time & energy, and you can't be sure you got away with it before actually doing it and waiting if your teammates will come kick you in the nuts. or worse, silently spend a day untangling their work.).

It's just fundamentally unsound.

[mehrdadn]

> But you can't safely rebase that branch!

Huh? You don't rebase their branch. You rebase your own changes on top of their branch, which they happened to recently rewrite. Just like you might rebase your changes on top of master after master has undergone changes. I think the parent's point was that it doesn't matter if the branch was rewritten or just extended; either way you rebase the same commits on it the same way. (If you're one of those people who's against the notion of rebasing entirely then that's a separate debate we can have another time, but you need to separate that from the force-push issue.)

[fulafel]

The "own" branch is also public here and maybe collaboratively worked on

[deathanatos]

The common case is that I'm working on a feature branch, and realistically, nobody else is on that branch. If it's so big that someone else has a need to start using the code, I start looking for ways to subdivide the work that don't conflict/depend (i.e., the new work can be a separate branch based off master).

There are definitely exceptions, and a co-worker that I work closely with have one just last week. My stuff is based off his. If he changes anything (adds new commits, or rewrites current ones), my "pull" is just to rebase onto whatever his new tip is. If I have a fix to his commit, I just commit that in my branch; at that point it isn't work the trouble. When we're done, we either merge his (and I rebase onto master) or we just feel lazy and merge both by merging my branch.

Having a branch on a branch on a branch has yet to happen, and honestly, at that point, I think we'd just wait for the upstream branch to land.

Honestly, for 99% of cases, you know what the effects of rebasing/rewriting will be. It's feature branch that only you're touching? Go wild! In the middle of a code-review? Maybe write the commits in the --auto-squash format, and wait until approval before actually running rebase. Someone else is based off it? Maybe give them a heads up. For the few spots where it's ambiguous, a little bit of "hey, I'd like to X for reasons Y, ok?" is all it takes.

[mehrdadn]

So then anyone building on it would rebase the same way you just did? Which was the same way they would have done so if you had just pushed a new commit?

[falsedan]

yeah exactly, all the FUD about rebase and shared branches is baffling to me. are people regularly getting stuck on 'git pull --rebase' and slamming into merge conflicts?