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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, May 8, 2023 at 12:01 AM Felipe Contreras
<felipe.contreras@xxxxxxxxx> wrote:
>
> Elijah Newren wrote:
> > On Wed, May 3, 2023 at 10:01 PM Tao Klerks <tao@xxxxxxxxxx> 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".
- 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. I'd love to see "git checkout" deprecated one day,
although I'm not sure I'll live to see it happen :)

>
> You want to strip away the options for experts, in search for what?

What *I* want is a generally safe system, in which you don't have to
be an expert to avoid causing yourself problems, especially losing
work.

The specific example that motivated my wanting to change "git
checkout" here was the case of a normal (non-expert, non-novice) user
who is used to doing "git checkout -b
actually-those-changes-I-made-shouldnt-go-on-the-branch-I-was-working-on-yet".
In their day-to-day work, that action will always have achieved
exactly what they wanted. The day they make exactly the same
invocation just before they commit a merge, it will do something
completely different and confusing - it will destroy a merge state,
and result in the commit, shortly after, being a regular non-merge
commot. Leveraging that committed tree in a merge commit *is* indeed
an expert action, and most novice and maybe intermediate users will
instead find themselves cursing git, and starting the merge again from
scratch - if they even notice the problem. If they don't notice the
problem, then they will instead have a new and fascinating source of
merge conflicts at some future time.

In general I *will* be willing to make things a little harder for
experts in favor of novices - absolutely.

That said, I don't believe the (new) change proposed here strips away
*useful* options from experts at all. When I said "safe-and-limiting",
I meant it in the most literal way - that there are some operations
that could be performed before and would achieve certain outcomes that
won't be possible afterwards. What I didn't mean to imply is that
those options are *valuable* to anyone - even to experts.

>
> 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.

I will provide a table of behaviors with a proposed patch in a few
days, but basically the main behavior we're taking away is a
one-command behavior of "switch branch and remove the (merge,
cherry-pick) in-progress state". The explicit equivalent is and will
continue to be "git [merge|cherry-pick] --quit && git checkout" -
leaving the in-progress merge changes in the index, but switching to
the specified branch.

My expectation is that this is not something even expert users find
themselves doing... ever. But I would like to know about it if I'm
wrong of course!

Something that I *do* see quite a lot in the test suite, and is
prompting my turn-about on "--force" support, is "git checkout -f
whatever" as a shorthand for "just get my worktree to the state of
that branch, regardless of the current ongoing operation".

This shorthand happens to *fail to work correctly* during a rebase
(clearing of the rebasing state was never implemented), but I believe
that has more to do with priorities and scope of changes than
intentional "let's set an extra-confusing trap for rebase" reasons.
The resulting state, where you have switched to the requested branch
and discarded any local changes, but are still in a rebase,
potentially with pending rebase sequence steps to complete, is not one
that I can see even expert users making constructive use of.

Generally, the "allow 'checkout --force' to destroy in-progress
operation states" behavior looks like an expert shortcut worth
preserving, and improving/fixing in the case of rebase.

>
> But this is not the proposal. The proposal is to break backwards compatibility
> for expert users with no way to retain the existing behavior.
>

It is true that the (updated) proposal closes the doors on *specific*
behaviors as a single command, requiring them to instead be spread
across two commands. However, I believe that those are effectively
*unused behaviors*, and that the increase in consistency and safety,
for all users, by far outweighs the cost of this particular break in
backwards compatibility.

I am, again, very interested in anything I might be missing!

> Generally, breaking backwards compatibility for no reason is frowned upon.
>

I absolutely understand and agree that breaking backwards
compatibility *for no reason* is never the right thing - and I take
note that being clear about exactly what the reasons are, and what the
costs are, *before* talking about doing it and asking for opinions, is
advisable and something that I failed to do sensibly here.

Thanks again for the feedback, please let me know if you know of any
useful expert use cases that I *am* missing in this updated proposal.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux