[mehrdadn]

> but it happens regularly in reviews

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.

[lmm]

> Again, you both know multiple people are involved here... "casually working together" is the heads-up! You don't need another one.

Well, one of force-pushing or casually working together had better be a rare exception, otherwise you'll do both at the same time. I'd rather not make force-pushing part of my normal workflow, because casually working together has more value to me.

> 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?

Anything committed / pushed is assumed working (we tend to compile before commit). If they need to rework their changes, they'll rework their changes, but the current state of their branch is almost certainly closer to the final state of their branch than the current state of master is.

> 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?

The trouble is it's viral. By the time you've figured out it's happened, other people have probably pulled from that branch; at best they've spent time merging in the force-pushed version. More likely they've done that and then built more work on top of it, so either both versions make it into mainline and everyone is resolving conflicts, or you have to ask that person to rebase their work and create another chance for the same problem to occur.

[mehrdadn]

> The trouble is it's viral. By the time you've figured out it's happened, other people have probably pulled from that branch; at best they've spent time merging in the force-pushed version. More likely they've done that and then built more work on top of it, so either both versions make it into mainline and everyone is resolving conflicts, or you have to ask that person to rebase their work and create another chance for the same problem to occur.

First, I don't understand how you're suggesting this situation arises. You're talking about a bunch of people all pulling from a branch while the only guy working on it is merrily force-pushing code and has absolutely no clue that anyone else is building work on top of it. Ignoring the questionable assumption that any commit on any branch is a sane one to build on top of -- why/how in the world is there zero communication on your team when you guys start building on each others' work?

Second... how is this any different from when the dev just gentle-pushes new commits instead of force-pushing?! You all will still end up having to resolve conflicts just the same when you rebase on top of their branch again... it sounds to me like what you're against is actually rebasing, only disguised as force-pushing.

[lmm]

> First, I don't understand how you're suggesting this situation arises. You're talking about a bunch of people all pulling from a branch while the only guy working on it is merrily force-pushing code and has absolutely no clue that anyone else is building work on top of it. Why in the world is there no communication on your team?

Code can be communication too. It's really nice to be able to just pull someone's branch (that they maybe mentioned in standup) without having to interrupt them to tell them you're doing it.

> Second... how is this any different from when the dev just gentle-pushes new commits instead of force-pushing?! You all will still end up having to resolve conflicts just the same when you rebase on top of their branch again... it sounds to me like what you're against is actually rebasing, only disguised as force-pushing.

When a dev gentle-pushes new commits and people merge them into their branches, it doesn't cause problems if they resolve conflicts differently, and other people who pull from their branches in turn don't have to keep re-resolving the same conflicts.

Rebase and force push are two sides of the same coin, let's not argue semantics. I say "no force pushing" rather than "no rebasing" because local rebase before you push doesn't cause problems.

[mehrdadn]

> Code can be communication too. It's really nice to be able to just pull someone's branch (that they maybe mentioned in standup) without having to interrupt them to tell them you're doing it.

But then if they communicated to you (during stand-up of whatever) their branch is ready to be used to build on, then they've made that code public and would avoid force-pushing, which is what I was saying? Conversely if they haven't told you then you wouldn't just randomly pick a commit and start building on it?

> When a dev gentle-pushes new commits and people merge them into their branches, it doesn't cause problems if they resolve conflicts differently, and other people who pull from their branches in turn don't have to keep re-resolving the same conflicts. > Rebase and force push are two sides of the same coin, let's not argue semantics. I say "no force pushing" rather than "no rebasing" because local rebase before you push doesn't cause problems.

AH so you're fundamentally against ever e.g. having a pull --rebase workflow on any branch you've ever pushed to any remote... regardless of who's working on what, what communication has occurred, whether that branch will even exist 2 hours from now, or whatever. Merge is the only valid approach in your mind, period. Honestly I have zero hope of trying to convince you merge isn't a size-fits-all dogma, so I won't try anymore except to point out that git supports both workflows for a reason, and its own documentation is clear that neither is strictly superior to the other: https://git-scm.com/book/en/v2/Git-Branching-Rebasing#_rebas...

[lmm]

> But then if they communicated to you (during stand-up of whatever) their branch is ready to be used to build on, then they've made that code public and would avoid force-pushing

Every morning everyone mentions what they're working on (and so implicitly what their current branches are about). Most of the time there's no particular reason to pick their branch up, but sometimes there is. The only way that can work is if you never force-push the branches you're working on.

> Conversely if they haven't told you then you wouldn't just randomly pick a commit and start building on it?

Anything that's pushed to the repo is presumed good to pick up, that's what the repo is for. If it's not ready for others to pick up then why push it to the repo at all?

> AH so you're fundamentally against ever e.g. having a pull --rebase workflow on any branch you've ever pushed to any remote... regardless of who's working on what, what communication has occurred, whether that branch will even exist 2 hours from now, or whatever. Merge is the only valid approach in your mind, period. Honestly I have zero hope of trying to convince you merge isn't a size-fits-all dogma, so I won't try anymore except to point out that git supports both workflows for a reason, and its own documentation is clear that neither is strictly superior to the other: https://git-scm.com/book/en/v2/Git-Branching-Rebasing#_rebas....

Did you read your own link? The last paragraph says exactly what I've been saying.

[mehrdadn]

> Anything that's pushed to the repo is presumed good to pick up, that's what the repo is for. If it's not ready for others to pick up then why push it to the repo at all?

You push... because you have 2+ repos you want to sync? Because you don't want to lose data if you mess things up locally? Because the remote repo runs tests on push that you want to run before you've finished the entire branch? Because someone else needs to be able to pick up your code if you get hit by a bus tomorrow? Because your boss or coworkers might need to be able to look at your code in an emergency? There are a million reasons to push that don't imply every commit on every pushed branch being suitable for splitting into another branch...

> Did you read your own link? The last paragraph says exactly what I've been saying.

It says that because they're (a) assuming if you've pushed code then you've probably published, which is a safer assumption but exactly what I've been arguing is not necessarily the case (and I've been trying to explain when it's not), and more generally (b) because they're erring on the side of caution. Which makes sense; I'd give the same advice to someone who's learning git. That's is exactly why the previous paragraph says "hopefully you’ll see that it’s not that simple" and "it’s up to you to decide which one is best for your particular situation". Those sentences aren't there for decoration. And it's why there is such a thing called a rebase workflow and why they made --force-with-lease and... again, I can't hope to convince you of the value of this workflow, just like how I can't convince you to use tabs over spaces (or tabs and spaces...). What I was doing was explaining how/when it can be useful while avoiding the problems you're hoping to avoid if you haven't already dogmatically rejected the rebase workflow from the start.