Junio C Hamano <gitster@xxxxxxxxx> writes: > I _think_ I am OK if we introduced "--allow-no-ff" that means the > current "--force" (i.e. "rewinding is OK"), that does not defeat the > "--lockref" safety. That is the intended application (you know that > push does not fast-forward because you rebased, but you also want to > make sure there is nothing you are losing by enforcing --lockref > safety). > > If that is what happens, then I think "--force" that means "anything > goes" makes sense. Or perhaps you were implicitly assuming that "--lockref" would automatically mean "I know I am rewinding, so as soon as I say --lockref, I mean --allow-no-ff", and I did not realize that. If that is the semantics you are proposing, then I think it makes sense to make "--force" the big red button that lets anything go. I was considering "--lockref" to be orthogonal to the traditional "ff only check", and rejecting a push when the updated ref's current value is expected (i.e. --lockref satisfied) but the update does not fast-forward, and that was where my resistance to allow "--force" to override "--lockref" comes from (because otherwise there is no way to say "I know I want to bypass 'ff-only' check, but instead make sure the current value is this"). -- 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