Vscode-gitlens: Use --force-with-lease instead of --force for forceful push

[JP-Ellis]

Currently, if one wishes to force push to a remote repository, GitLens appears to use git push --force. This is a rather brute-force approach and can result in accidentally overriding changes on the remote that may have been pushed since you last fetched.

For example, if I push a commit and realise soon after that I made a small mistake and amend that commit, a git push --force will override changes on remote that may have been pushed in that intervening time.

Replacing git push --force with git push --force-with-lease instead should be a simple change which will help ensure that new changes on the remote aren't accidentally overridden if the person making the push isn't aware of them before hand. Specifically, as described in the git man page:

       --[no-]force-with-lease, --force-with-lease=<refname>,
       --force-with-lease=<refname>:<expect>
           Usually, "git push" refuses to update a remote ref that is not an ancestor
           of the local ref used to overwrite it.

           This option overrides this restriction if the current value of the remote
           ref is the expected value. "git push" fails otherwise.

           Imagine that you have to rebase what you have already published. You will
           have to bypass the "must fast-forward" rule in order to replace the history
           you originally published with the rebased history. If somebody else built on
           top of your original history while you are rebasing, the tip of the branch
           at the remote may advance with her commit, and blindly pushing with --force
           will lose her work.

           This option allows you to say that you expect the history you are updating
           is what you rebased and want to replace. If the remote ref still points at
           the commit you specified, you can be sure that no other people did anything
           to the ref. It is like taking a "lease" on the ref without explicitly
           locking it, and the remote ref is updated only if the "lease" is still
           valid.

           --force-with-lease alone, without specifying the details, will protect all
           remote refs that are going to be updated by requiring their current value to
           be the same as the remote-tracking branch we have for them.

           [...]

           A general note on safety: supplying this option without an expected value,
           i.e. as --force-with-lease or --force-with-lease=<refname> interacts very
           badly with anything that implicitly runs git fetch on the remote to be
           pushed to in the background, e.g.  git fetch origin on your repository in a
           cronjob.

           The protection it offers over --force is ensuring that subsequent changes
           your work wasn’t based on aren’t clobbered, but this is trivially defeated
           if some background process is updating refs in the background. We don’t have
           anything except the remote tracking info to go by as a heuristic for refs
           you’re expected to have seen & are willing to clobber.

As far as I understand, there should be no adverse effect resulting from implementing this change.

[baob]

Absolutely. Allowing --force is an unsafe practice, even in the context if single-user repos. IMHO if you can't fix it with --force-with-lease you should probably take a close look at how you got there and thinking about how to avoid that situation in future.

[eamodio]

Currently GitLens, just executes vs code's built-in git.pushForce command when you use the force push. You can change the behavior of that command by setting "git.useForcePushWithLease": true in your settings.

Hope that helps!

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.