Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > I.e. making plain --force-with-lease harder to use by hiding it behind a > config option gives the user fewer options than with --force to recover. I agree with that. But I would consider it a good thing, if done properly (i.e. suggest --force-with-lease that is not a lzzy form). > So I think we should still recommend the longer and even safer variants > of --force-with-lease, but being guaranteed to have the SHA-1 you just > clobbered locally is *better*, and allows us to e.g. do this: > > $ git push --force-with-lease > hint: You just clobbered <X> on <remote with <Y>. If you regret > hint: this you can (until the object gets pruned) do: > hint: git push <remote> --force-with-lease=<refname>:<Y> Until the object gets pruned, and until somebody else pushes there to make the damage bigger, you can recover from a mistake with that information. It probably is a bug that the lazy force-with-lease does not report what the remote tip you just overwrote was, and this would help great deal. It would be a good place to start. One thing that I am still not clear how this line of thought truly would help users is how to help them decide their answer to "If you regret this". An unthinking naïve user would say "of course I meant it when I gave the option---why do you think I regret it?" without a bit more hint, namely, "<Y> was taken from the remote tracking branch, are you sure that is still what the newly prepared contents you built to replace? Did somebody clobber it while you are not watching?" These three lines however will be felt too loud by those who would most benefit from them (i.e. those who do not know why they need protection); I do not think advise.* to allow them to be squelched would be appropriate.