From: Felipe Contreras <felipe.contreras@gmail.com>
To: Tao Klerks <tao@klerks.biz>,
Felipe Contreras <felipe.contreras@gmail.com>
Cc: 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 10:13:49 -0600 [thread overview]
Message-ID: <64591fbddaf2d_7c6829457@chronos.notmuch> (raw)
In-Reply-To: <CAPMMpojTjFn7JCo8QsDcOJf6NoJYASbV1bL_JxDhUr7DS12DJg@mail.gmail.com>
Tao Klerks wrote:
> On Mon, May 8, 2023 at 12:01 AM Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
> > Elijah Newren wrote:
> > > On Wed, May 3, 2023 at 10:01 PM Tao Klerks <tao@klerks.biz> wrote:
> >
> > > > If we are comfortable changing the behavior of branch checkout to be
> > > > safe-and-limiting like switch, then that should be almost as simple as
> > > > removing that condition.
> > >
> > > I've never heard a dissenting vote against this
> >
> > Here is my dissenting vote: I'm against this change.
> >
> > If I want to use a high-level command meant for novices, I use `git switch`. If
> > instead I simply want to switch to a different commit and I want git to shut up
> > about it, then I use `git checkout`.
>
> Thank you for your perspective on the relationship between these commands.
>
> I don't fully share this perspective, in two ways:
> - In my experience most novices don't see or know about "git switch"
> at all - the vast majority of the internet is still stuck on "git
> checkout", as are existing users. Google search result counts are of
> course a poor metric of anything, but compare 100k for "git switch" to
> 2.4M for "git checkout".
Yes, but that's something for the Git community to fix.
Why can't the git developers communicate effectively with the user base?
> - As far as I can tell, "git switch" and "git restore" have exactly
> the same power and expressiveness (except specifically the lack of
> "git switch --force" support for bulldozing ongoing merges) - they are
> just as much "expert" tools as "git checkout"; the main way they
> differ is that they are clearer about what they're doing / what
> they're for.
That is not true, you can't do `git switch master^0` because that would be
potentially confusing to new users, but you can do the same with `git
checkout`.
> I'd love to see "git checkout" deprecated one day, although I'm not
> sure I'll live to see it happen :)
But that's not an excuse to break user experience.
> > If there was a way of doing:
> >
> > git -c core.iknowwhatimdoing=true checkout $whatever
> >
> > Then I wouldn't oppose such change.
>
> I know I keep wavering back and forth on this, my apologies for my
> inconstancy: *I once again think adding support for "--force" (to
> checkout and switch) with ongoing operations makes sense.*
>
> This does not achieve exactly what you seem to be suggesting above,
> for two reasons:
> 1. It could not be implicit in config, but rather would need to be
> explicit in the command
> 2. The outcome of using --force is not exactly the same as "git
> checkout" without it (but that's a good thing)
>
> I would (and will) argue that not achieving exactly what you propose
> *is OK* because the behavior of "git checkout", without "--force",
> when there is a (merge, rebase, cherry-pick, am, bisect) operation in
> course, especially the way that behavior differs from when "--force"
> is specified, is *not useful* - even to expert users.
OK. That may be the case.
But it wouldn't be the first time some operation is considered not
useful, and then it turns out people did in fact use it.
I would be much more confortable if there was a way to retain the
current behavior, but if we are 99.99% positive nobody is actually
relying on this behavior, we could chose to roll the die and see what
happens (hopefully nobody will shout).
But if that's the case, I think this is something that should be a
conscious decision that is extremely clear in the commit message.
Cheers.
--
Felipe Contreras
next prev parent reply other threads:[~2023-05-08 16:14 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 [this message]
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=64591fbddaf2d_7c6829457@chronos.notmuch \
--to=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).