Re: [PATCH] RFC: switch: allow same-commit switch during merge if conflicts resolved

[Felipe Contreras <felipe.contreras@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