From: Tao Klerks <tao@klerks.biz>
To: Elijah Newren <newren@gmail.com>
Cc: Tao Klerks via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH] RFC: switch: allow same-commit switch during merge if conflicts resolved
Date: Fri, 5 May 2023 07:06:15 +0200 [thread overview]
Message-ID: <CAPMMpoi7+rdQzQPyVB8T9Pb+f332c68QvWLkwBdJZw=BcP0jbQ@mail.gmail.com> (raw)
In-Reply-To: <CAPMMpogiTVksUKgZ==n4d3xm4ZJqxm7ki2dOF8j8S5BaJvu1Ew@mail.gmail.com>
On Thu, May 4, 2023 at 7:01 AM Tao Klerks <tao@klerks.biz> wrote:
>
> Please let me know whether you would be comfortable with a patch that:
> * Fixed checkout to be more restrictive (except still allowing --force
> at least on a merging state)
> [...]
Having reviewed the commit by Nguyễn Thái Ngọc Duy that introduced the
"can_switch_when_in_progress" boolean in 2019 (as part of the broader
introduction of "git switch" and "git restore"), it looks like I
should change my proposal here. I thought it made sense to continue to
support --force because we can, but I now think this is wrong,
because:
1. the fact that --force does not work in git switch is *intentional*
2. even though making it work for "merging" states would be trivial,
making it work during rebase would not be
3. the blocking of --force is not a significant inconvenience, as the
error message clearly tells you what to do (--quit), to continue on
your way
So I will set about trying to understand how to make this one-line
change work. I already see that some tests rely on "git checkout -f"
bulldozing through an ongoing merge, so those tests will need to be
adjusted at least.
Are there any recommendations or processes around breaking changes for
the git project anywhere? The specific behaviors that we would be
changing here appear to be undocumented (I've looked through
https://git-scm.com/docs/git-checkout at least and find no mention or
expectation that switching during a merge, or rebase, etc is
supported; nor do I see any explicit mention in
https://git-scm.com/docs/git-switch that it is UNsupported)
ASIDE: I realized today that the warnings in
die_if_some_operation_in_progress() suggest "--quit" (potentially
leaving a conflicted index) and do not mention "--abort". Is there any
objection to beefing up these messages a bit to offer both options?
next prev parent reply other threads:[~2023-05-05 5:06 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 [this message]
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
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='CAPMMpoi7+rdQzQPyVB8T9Pb+f332c68QvWLkwBdJZw=BcP0jbQ@mail.gmail.com' \
--to=tao@klerks.biz \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
--cc=newren@gmail.com \
/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).