Am 10.07.2013 01:08, schrieb Junio C Hamano:
> Junio C Hamano <gits...@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
>> 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?
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html