Johannes Sixt <j...@kdbg.org> writes: > No. --force means "I know what I am doing, no safety needed, thank you".
I sympathize the desire to keep a big red button to override everything, but it is still not clear how these two independent safety should work together and should possibly seletively be overriden. A proposed ref update can be in one of the four: 1. The update fast-forwards, and the ref to be updated is at the expected place (or you simply do not care what the current value is); 2. The update does not fast-forward, and the ref to be updated is at the expected place (or you simply do not care what the current value is); 3. The update fast-forwards, but the ref to be updated is not at the expected place; or 4. The update does not fast-forward, and the ref to be updated is not at the expected place. So far we had only 1. and 2. because we did not have this "old value has to be at X". And --force has been the way to allow 2. to go through. Now we are adding 3. and 4. to the mix. If --force were the big red button that allows all four, is that sufficient to cover the necessary cases, especially given that some people seem to want to make the --lockref on by default (implying that 3. and 4. will both fail by default unless forced in some way)? For example, would there be a case where we want to allow 3. but not 4. (or vice versa)? You _could_ structure the safety into hierarchies: * safest: no-ff will be rejected, and current value at an unexpected place is also rejected. That would be: $ git push --lockref * --lockref only: no-ff is not even checked, but current value must be at an expected place. How would that be spelled??? $ git push --lockref ??? * --force: anything goes. $ git push --force --no-lockref Where does "ff-check only" fit in the hierarchy? This is one of the reasons why the original design of "--lockref" was to even countermand "allow non-fast-forward" (which is the original meaning of "--force"). 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. With the posted series, adding "--force --no-lockref" to the command line is how to spell that big red button. -- 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