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

[Johannes Sixt <j6t@kdbg.org>]

Am 10.07.2013 01:08, schrieb Junio C Hamano:
> 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.

That's what I mean, sort of. Because of your 4 cases of a ref update, I
do not think that

> 3. The update fast-forwards, but the ref to be updated is not at the
>    expected place; or

is important to consider. The point of --lockref is to avoid data loss,
but if the push is fast-forward, there is no data loss.

> 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").

Again: Why not just define +refspec as the way to achieve this check?

-- Hannes