On Wed, May 05 2021, Sergey Organov wrote: > Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > >> On Tue, May 04 2021, Elijah Newren wrote: >> >>> On Tue, May 4, 2021 at 3:36 AM Gábor Farkas <gabor.farkas@xxxxxxxxx> wrote: >>>> >>>> hi, >>>> >>>> the "git switch" and "git restore" commands were released two years >>>> ago, but the manpage still says "THIS COMMAND IS EXPERIMENTAL. THE >>>> BEHAVIOR MAY CHANGE.". >>>> >>>> i'd love to use them, but this warning gives me pause, perhaps i >>>> should wait until it stops being experimental, i worry that it might >>>> change in behavior unexpectedly and cause problems for me. >>>> >>>> considering that they were released two years ago, could the >>>> experimental-warning be removed now? >>>> >>>> thanks, >>>> gabor >>> >>> This probably makes sense. The author of switch and restore isn't >>> involved in the git project anymore. He decided to work on other >>> things, which was and is a big loss for us. I think others (myself >>> included) didn't know all the things that might have been in Duy's >>> head that he wanted to verify were working well before marking this as >>> good, but these two commands have generally been very well received >>> and it has been a few years. Personally, I'm not aware of anything >>> that we'd need or want to change with these commands. >> >> I am. >> > > [...] > >> And: >> >> # Moves a branch (or -M for --force) >> git branch -m old new >> >> That last one we can't have either because "switch" squats on "-m" for >> "--merge", which I daresay is a much more obscure use-case not deserving >> of a short option than "rename and switch to". > > Isn't --merge a different (and inferior) way to achieve what we already > have elsewhere with --autostash? Does it make sense to get rid of --merge > here in favor of --autostash? Probably, I haven't used the --merge option ever I think. Switching with dirty worktrees isn't really how I work. But to the extent that I've ever tried / run into errors with that I'd think that an option like --merge or --autostash is mostly a result of us being overzealous about "is_dirty() && die()" checks. E.g. rebase (at least a while ago, still) would refuse to rebase with a dirty tree, even though the path in question had nothing to do with paths that would be touched by the rebase. I suspect that much of the need for these sorts of options would go away with those checks being smarter, but it's separate from the "should we squat on -m" discussion...