From: Junio C Hamano <gitster@pobox.com>
To: Tao Klerks <tao@klerks.biz>
Cc: Felipe Contreras <felipe.contreras@gmail.com>,
Elijah Newren <newren@gmail.com>,
Tao Klerks via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org
Subject: Re: [PATCH] RFC: switch: allow same-commit switch during merge if conflicts resolved
Date: Mon, 08 May 2023 12:18:45 -0700 [thread overview]
Message-ID: <xmqqzg6eocmi.fsf@gitster.g> (raw)
In-Reply-To: CAPMMpoi74RFBptKkv23FSK-fQsnuan9EK5HodUBRLNtxLYdr_w@mail.gmail.com
Tao Klerks <tao@klerks.biz> 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.
next prev parent reply other threads:[~2023-05-08 19:19 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-02 6:27 [PATCH] RFC: switch: allow same-commit switch during merge if conflicts resolved Tao Klerks via GitGitGadget
2023-05-02 15:55 ` Elijah Newren
2023-05-02 16:50 ` Junio C Hamano
2023-05-03 0:34 ` Elijah Newren
2023-05-04 5:01 ` Tao Klerks
2023-05-05 5:06 ` Tao Klerks
2023-05-07 2:57 ` Elijah Newren
2023-05-07 2:48 ` Elijah Newren
2023-05-07 22:01 ` Felipe Contreras
2023-05-08 8:30 ` Tao Klerks
2023-05-08 16:13 ` Felipe Contreras
2023-05-08 16:58 ` Tao Klerks
2023-05-08 19:18 ` Junio C Hamano [this message]
2023-05-09 1:55 ` Felipe Contreras
2023-05-08 10:44 ` Tao Klerks
2023-05-11 7:06 ` Elijah Newren
2023-05-21 20:08 ` Tao Klerks
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqzg6eocmi.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=felipe.contreras@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=newren@gmail.com \
--cc=tao@klerks.biz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).