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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html