Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > Document & test for cases where there are two remotes pointing to the > same URL, and a background fetch & subsequent `git push > --force-with-lease` shouldn't clobber un-updated references we haven't > fetched. > > Some editors like Microsoft's VSC have a feature to auto-fetch in the > background, this bypasses the protections offered by > --force-with-lease as noted in the documentation being added here. That sounds like an unfortunate mix of two "feature"s that are mutually incompatible. Perhaps those who thought auto-fetch was a good idea didn't think through the implications, and also it is understandable that those who never thought auto-fetch was a good idea would want --force-with-lease to default to the remote-tracking branch. > diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt > index 1624a35888..2f2e9c078b 100644 > --- a/Documentation/git-push.txt > +++ b/Documentation/git-push.txt > @@ -210,6 +210,43 @@ or we do not even have to have such a remote-tracking branch when > this form is used). If `<expect>` is the empty string, then the named ref > must not already exist. > + > +This option interacts very badly with anything that implicitly runs > +`git fetch` on the remote to be pushed to in the background. The This description is not accurate. Only those who do not to specify what is expected and instead use the remote-tracking branch are affected (but these random "git fetch" clobbering the remote-tracking branch is sort of known and expected). I do not think I would mind if these two new lines were added one paragraph above, i.e. where "--force-with-lease=<refname>" form is described. It clearly says "... as the remote-tracking branch we have for them." and that is the best place to say "This option interacts badly".