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