Tao Klerks wrote: > On Mon, May 8, 2023 at 6:13 PM Felipe Contreras > <felipe.contreras@xxxxxxxxx> wrote: > > 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? > > 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
