Tao Klerks wrote: > 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". 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
