Tao Klerks <tao@xxxxxxxxxx> writes: > The question, I understand, is whether there should be a "git -c > core.suckycheckoutstatemanagement=true checkout" option *just in > case*, so any affected automation users could set it, fix their > affected automated processes, and then remove it, before we finally > remove the "core.suckycheckoutstatemanagement" option in a subsequent > release. If a new behaviour is hidden behind a new option nobody has heard of before, you would not risk breaking anybody who wrote their scripts long time ago and have relied on them the way they currently work, and the new option would not have to be removed at all. I think the "switch" was written exactly for such a transition so that folks who wanted a different behaviour do not have to break existing users of "checkout". Do we still mark "switch" as experimental in bold red letters in the documentation? Then it is not too late to improve the end-user experimence with the command without worrying about too much about backward compatibility.
