From: Junio C Hamano <gitster@pobox.com>
To: Elijah Newren <newren@gmail.com>
Cc: Tao Klerks via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, Tao Klerks <tao@klerks.biz>
Subject: Re: [PATCH] RFC: switch: allow same-commit switch during merge if conflicts resolved
Date: Tue, 02 May 2023 09:50:25 -0700 [thread overview]
Message-ID: <xmqq1qjy1xv2.fsf@gitster.g> (raw)
In-Reply-To: CABPp-BH8A=CnO3_UWXDegb87VTNEX8s+=CefB90m1_vjBZ_+Fw@mail.gmail.com
Elijah Newren <newren@gmail.com> writes:
> By the way, it was a problem that git-checkout wasn't updated to have
> the same safety that git-switch has. We should fix that. (It's on my
> todo list, along with adding other
> prevent-erroneous-command-while-in-middle-of-other-operation cases.)
Yes.
> I'm worried this is likely to lead us into confusing UI mismatches,
> and makes it harder to understand the appropriate rules of what can
> and cannot be done. A very simple "no switching branches in the
> middle of operations" is a very simple rule, and saves users from lots
> of headaches.
>
> Granted, expert users may understand that with the commit being the
> same, there is no issue. But expert users can use `git update-ref` to
> tweak HEAD, or edit .git/HEAD directly, and accept the consequences.
> Why do we need to confuse the UI for the sake of expert users who
> already have an escape hatch?
>
> More importantly, though...
>
>> Change the behavior of "git switch" and "git checkout" to no longer delete
>> merge metadata, nor prohibit the switch, if a merge is in progress and the
>> commit being switched to is the same commit the HEAD was previously set to.
>
> Even if there are conflicts? For rebases, cherry-picks, ams, and
> reverts too? (Does allowing this during rebases and whatnot mean that
> --abort becomes really funny? Does it mean that some commits are
> applied to one branch, and all commits are applied to another? What
> about autostashes? Does it interact weirdly with --update-refs?
> etc.)
>
> I think this change is premature unless it discusses all these cases,
It is pretty much what I wanted to say about why we haven't done
this in <https://lore.kernel.org/git/xmqqpm7k6ojz.fsf@gitster.g/>,
so it makes two of us ;-). I didn't look at Tao's RFC patch but if
the way it determines "we are in a middle of conflicted merge and
we'll allow switching to the same commit only in this case" were
"the index has an unmerged entry", then it is an overly broad test
and the consequences of allowing the switch for these other merge-y
operations that are ongoing must be evaluated.
Thanks.
next prev parent reply other threads:[~2023-05-02 16:50 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 [this message]
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
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=xmqq1qjy1xv2.fsf@gitster.g \
--to=gitster@pobox.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).