On Wed, Jul 5, 2017 at 1:26 PM, Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: > > 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 mean reduction in risk... > 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.
