On Wed, Jul 05 2017, Junio C. Hamano jotted: > On Tue, Jul 4, 2017 at 11:34 PM, Francesco Mazzoli <f@xxxxxxxx> wrote: >> >> Could you clarify the danger you're referring to? E.g. give an example >> of surprising --force-with-lease behavior that we do not want to >> encourage? > > https://public-inbox.org/git/1491617750.2149.10.camel@xxxxxxxxxxxxxxxxx/ In the context of this patch I don't understand why you're concerned that making --force mean --force-with-lease makes things worse. See my https://public-inbox.org/git/CACBZZX48RanjHsv1UsnxkbxRtqKRGgMcgmtVqQmR84H5j8awqQ@xxxxxxxxxxxxxx/ (follow-up to the E-Mail you posted): To me the *main* feature of --force-with-lease is that it's less shitty than --force, without imposing too much UI overhead. We have to be really careful not to make --force-with-lease so complex by default that people just give u and go back to using --force, which would be worse than either whatever current problems there are with the current --force-with-lease behavior, or anything we replace it with. I.e. yes there are workflows with some background auto-update that will make it less safe, which I documented in f17d642d3b ("push: document & test --force-with-lease with multiple remotes", 2017-04-19). But it is still the case that --force-with-lease is categorically a more safer option than simply --force, which has none of the safety --force-with-lease has. It would still wipe away history in this scenario you're pointing out *and others*. Surely the point of having an option like this is to have a net reduction in complexity. I think it can be argued that it's bad UI design though to have --force mean different things depending on the config, and we'd be better off with a patch that disables --force.
