Re: [PATCH 7/7] push: document --lockref

[Junio C Hamano <gitster@pobox.com>]

Junio C Hamano <gitster@pobox.com> 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").