Hi Junio,
On Mon, 10 Jul 2017, Junio C Hamano wrote:
> * jc/allow-lazy-cas (2017-07-06) 1 commit
> - push: disable lazy --force-with-lease by default
>
> Because "git push --force-with-lease[=<ref>]" that relies on the
> stability of remote-tracking branches is unsafe when something
> fetches into the repository behind user's back, it is now disabled
> by default. A new configuration variable can be used to enable it
> by users who know what they are doing. This would pave the way to
> possibly turn `--force` into `--force-with-lease`.
>
> Will wait for feedback, then merge to and cook in 'next'.
I wonder whether the --force-with-lease option would benefit (and counter
the "unsafe because of behind-the-back operations" argument) from doing
some kind of "reverse pull --rebase".
In other words, --force-with-lease could verify that the upstream branch
has no commits that weren't seen in the current branch's reflog, i.e. that
`git rev-parse HEAD@{upstream}` is identical to `git merge-base
--fork-point HEAD HEAD@{upstream}`.
The assumption would be that you typically want to push with a lease only
when following the `pull --rebase` workflow. Meaning that you would only
want to force-push when your local branch had the upstream branch
integrated at some stage [*1*].
I could imagine, though, that this should be an opt-in option for now, and
could be turned into an opt-out option later. Or maybe just make it
opt-out, adding a kick-ass error message explaining the situation properly
(and how to override the safe-guard from the command-line).
Ciao,
Dscho
Footnote *1*: Of course, if you merge upstream, do some stuff and then
reset --hard to the previous state, this safeguard will not catch. It
would *still* catch when aborting a rebase onto upstream, though.
