Subject: Re: [PATCH] RFC: switch: allow same-commit switch during merge if conflicts resolved

From: Junio C Hamano <[email-masked]>
Date: Mon, 08 May 2023 12:18:45 -0700

Tao Klerks <[email-masked]> 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.