From: Duy Nguyen <pclouds@gmail.com>
Date: Tue, 09 Jun 2015 23:24:26 GMT
Subject: Re: On undoing a forced push
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