But then you already know someone is reviewing that branch! So both of you avoid force-pushing.
> or when casually working together on the same thing in
Again, you both know multiple people are involved here... "casually working together" is the heads-up! You don't need another one.
> or when basing branches on other people's unfinalized work
Without any sort of hint to the guy working on that branch? How do you know it's even in a stable state to build on if you have no communication?
> or they do a force push out of habit
Yes it breaks if you screw up, but I mean then you just deal with it right? It's a dumb mistake just like any other silly mistake that can happen during committing, it's infrequent, it's on an ephemeral branch, and it's completely reversible. I don't see why someone occasionally mistakenly pushing the wrong thing (forced or otherwise) on a branch that isn't even going to exist for much longer is such a catastrophic event that you have to formulate your whole team's entire development process around avoiding that event 100% at all costs?
> Your proposed "heads up" way can work in theory, but it introduces too much friction and risk of error, and still leaves the situation in shambles when they have a rebased branch on their laptop that they haven't pushed yet. So you need to have a multi phase protocol that requires many interactions and even then the other guy may well forget about it and do a rebase & force push out of habit in the end.
Again, you don't need an explicit heads-up when you already know multiple people involved, and you can just deal with the occasional errors, as I mentioned. See above.
