Re: What's cooking in git.git (Jul 2017, #03; Mon, 10)

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

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.