Re: On undoing a forced push

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

Hi,

On 2015-06-09 16:06, Sitaram Chamarty wrote:
> On 06/09/2015 05:42 PM, Duy Nguyen wrote:
>> From a thread on Hacker News. It seems that if a user does not have
>> access to the remote's reflog and accidentally forces a push to a ref,
>> how does he recover it? In order to force push again to revert it
>> back, he would need to know the remote's old SHA-1. Local reflog does
>> not help because remote refs are not updated during a push.
>>
>> This patch prints the latest SHA-1 before the forced push in full. He
>> then can do
>>
>>     git push <remote> +<old-sha1>:<ref>
>>
>> He does not even need to have the objects that <old-sha1> refers
>> to. We could simply push an empty pack and the the remote will happily
>> accept the force, assuming garbage collection has not happened. But
>> that's another and a little more complex patch.
> 
> If I am not mistaken, we actively prevent people from downloading an
> unreferenced SHA (such as would happen if you overwrote refs that
> contained sensitive information like passwords).
> 
> Wouldn't allowing the kind of push you just described, require negating
> that protection?

I believe that to be the case.

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).

Ciao,
Johannes