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

Johannes Sixt <j6t@kdbg.org> writes:

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.