Re: On undoing a forced push

From: Duy Nguyen <pclouds@gmail.com>
Date: Jun 9, 2015, 23:24 UTC
Message-ID: <CACsJy8BDhuk8efFrCPH4FWxbFt-3iqrS6AMLeQso5YPUHmTZwg@mail.gmail.com>
In-Reply-To: <012a980b0b9f1aa394e2b3701e4e6f97@www.dscho.org>

On Tue, Jun 9, 2015 at 11:29 PM, Johannes Schindelin <johannes.schindelin@gmx.de> wrote:

> Sorry to chime in so late in the discussion, but I think that the `--force-with-lease` option is what you are looking for. It allows you to force-push *but only* if the forced push would overwrite the ref we expect, i.e. (simplified, but you get the idea) `git push --force-with-lease <remote> <ref>` will *only* succeed if the remote's <ref> agrees with the local `refs/remotes/<remote>/<ref>`.
>
> If you use `--force-with-lease`, you simply cannot force-forget anything on the remote side that you cannot undo (because you have everything locally you need to undo it).

Yeah I recall Junio did something about pushes.. I was about to suggest that we promote force-with-lease to default --force and current --force becomes --force --force. But there's this from commit 2233ad4 (Merge branch 'jc/push-cas' - 2013-09-09) that makes me hesitate

    The logic to choose the default implemented here is fragile
    (e.g. "git fetch" after seeing a failure will update the
    remote-tracking branch and will make the next "push" pass,
    defeating the safety pretty easily).  It is suitable only for the
    simplest workflows, and it may hurt users more than it helps them.

Either way I still want to provide an escape hatch for --force as it's good to reduce the number of unrecoverable operations down.

-- 
Duy