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 19:55:32 -0600 [thread overview]
Message-ID: <6459a814ee378_7c682949e@chronos.notmuch> (raw)
In-Reply-To: <CAPMMpoi74RFBptKkv23FSK-fQsnuan9EK5HodUBRLNtxLYdr_w@mail.gmail.com>
Tao Klerks wrote:
> On Mon, May 8, 2023 at 6:13 PM Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
> > 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?
>
> Emm... I'm going to take that as a rhetorical question, since you've
> been around these parts for a lot longer than I have :)
>
> (I have opinions, but they are not pertinent to this thread, and I
> don't have meaningful solutions)
Yes, it was rhetorical.
That being said, if you feel like sharing that opinion off the record,
I'm interested in hearing it.
> > > - 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`.
>
> Ah, I see your point - git switch requires you to be more verbose in
> this case, specifying an extra --detach.
Yes, because it's meant for more novice users.
> > > > 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).
>
> It sounds like you're distinguishing here between "options for
> experts" (which should be valuable to warrant influencing the
> long-term design) and "behavior that users and systems may have come
> to rely on".
Sure, they are different, but they are related.
If somebody has only one week of expertice with git, I think it's safe
to say they don't rely on the current behavior that much.
On the other hand somebody who has 15 years of experience with git has a
higher chance of relying on the current behavior.
> As I've argued here, I believe that the current behavior
> is not *useful*, and thus a "but the expert users" argument doesn't
> sway me at all...
And you may be right, I'm not going to argue against such claim.
But this is an argument from ignorance fallacy. The last time I argued
"I cannot imagine how X might be the case" turned out X was the case.
> I can't imagine this pattern being used in real-life automation, but
> like anyone my imagination is limited.
Indeed.
Once again: I'm not saying this is going to break user expectations,
because it might not. I'm saying this *might* break user expectations,
but we could still roll the dice and find out.
Ultimately this is not my decision, it's the decision of the maintainer.
> Here is precisely where I don't know how to judge "breakage risk and
> value of being able to revert behavior without downgrading git" vs
> "complexity of implementation and communication". Obviously I would
> prefer not to do a bunch of valueless work implementing and supporting
> an option that no-one would ever use, and removing it a couple months
> later.
Agreed, which is why I'm not suggesting this work has to be done, but
the maintainer might (I've often done what I consider unnecessary work
just because of that reason).
All I'm saying is that because the git project puts a premium on
preserving backwards compatibility (as any decent software project
should), then:
> > 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-09 1:55 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
2023-05-09 1:55 ` Felipe Contreras [this message]
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=6459a814ee378_7c682949e@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).