[kazinator]

You'd have to interrupt your own activity of synchronizing one of your downstream repos with your upstream, and force-publishing something back upstream, by switching to another one of the downstreams and publishing something into the upstream, which is then clobbered when you resume the original activity. Basically, split personality disorder where some of the personalities are not aware of the others.

All of this still overlooks the fact that the changes are not lost. Say someone (like one of the personalities in your head you don't know about) publishes a change which you unknowingly clobber with a "git push --force". That someone will notice when they fetch the repo: it has diverged from their clone and when they look at the history of master vs origin/master, they will see that their commit which they are sure they pushed does not appear in origin/master.

If you have multiple downstream checkouts and manage to clobber something with force pushes, you can recover. Then have a word with yourself and work smarter going forward.

[robertlagrant]

All force-with-lease does it stop you from clobbering rather than you having to realise somehow that you did that. It seems like a no-brainer. What's the problem with it?

[kazinator]

The only situations in which I would use a git push --force would be in which I have carefully considered what state the remote is in, and what state I want it to be be in, and I know that it's not a moving target it any way in between checking its state and doing the force.

Already, "git push" stops from clobbering: it warns that your proposed push is non-fast-forward and that you need --force.

If you are using git as intended, that's all the warning you need.

I understand that there are dubious workflows out there where a repo has multiple downstream users and they are all doing "git push --force", without coordinating with each other. They need a double force to make sure that they are clobbering what they think they are clobbering.

If that's not you (which it arguably shouldn't be, and certainly isn't me), you don't need to know about force-with-lease.

The only thing I would ever do with --force-with-lease is go "oh", and immediately repeat the command with --force, knowing that I'm in a situation in which the check is not applicable.

Even if the force were erasing a new commit that came from another repo, I would know that. Like I pushed something into upstream U from repo B, but I'm fixing the situation out of repo A which hasn't picked up the change. Yes, I know what I'm doing, that's why I'm using --force, and don't require --simon-says-force. I want the chain of commits I now have in A to be exactly what is in U, as a rare exception to normal git use. After I'm done from A, I will switch back to B, do a "git fetch" and probably "git reset --hard origin/master" to make B look like U.

[robertlagrant]

Hm - I think I follow. But say I push a commit on a branch, then realise I messed up the commit message, so I --amend and push. I know that git push will fail, but if I git push -f then it won't detect that someone else pushed to the same branch in between - it'll just silently wipe their push.

Using --force-with-lease means the git push -f will succeed if no-one's pushed in between, and fail otherwise.