Description
The --force-with-lease
option ensures that you can only force-push updates where your remote-tracking ref agrees with the remote ref.
Obviously, the idea was that if you call git pull <remote>
, you will have seen and incorporated the remote commits, even if you rebased and the result therefore does not fast-forward.
However, one rather common setup is ignored by this idea: Git UIs often "helpfully" fetch in the background. And that does not update the local branch, therefore it is quite possible to lose commits inadvertently.
On the mailing list, I proposed the following strategy:
The new behavior would look at the reflog, much as the
--fork-point
option ofgit rebase
: in addition to the regular--orce-with-lease
server-side checks, a client-side check first verifies that the remote-tracking branch is reachable at least from one of the items in the reflog of the branch we are about to push.That is, it would ensure that even if we rebased locally, we did incorporate the tip commit of the remote-tracking branch, at some stage.
Granted, there are probably cases where you would fetch, look at the remote-tracking branch, and reject those changes without integrating those into the local branch. In that case, you would want to relax to the current behavior of
--force-with-lease
. But I would expect that to happen only rarely.The safety by the proposed behavior would make it a lot easier to accept a config setting that makes this the default.