Johannes Sixt <j6t@xxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html