I’ve been using the newer commands like switch and restore for a while. But I learned a few things here that will indeed make my work easier.

Additionally, switch performs extra sanity checks that checkout doesn’t, for example switch would abort operation if it would lead to loss of local changes.

What checks? Under what situation does checkout lead to loss of changes? If I make changes and attempt to checkout a ref that would overwrite them, I get the following error:

error: Your local changes to the following files would be overwritten by checkout:
        some/file
Please commit your changes or stash them before you switch branches.
Aborting

To my knowledge it’s not possible to overwrite changes when switching branches/refs (git checkout <ref> without any other arguments or flags) so I guess what the author really means is, “If you use checkout incorrectly you can overwrite local changes.” As far as I can recall I’ve never accidentally git checkout <ref> <some/file> so I don’t see a reason to retrain my muscle memory. I do use git restore since it’s behavior is a lot more obvious than checkout/reset though sometimes I still use git checkout <ref> -- <some/file> because muscle memory.

I should really start using switch and restore. I haven’t destroyed work yet due to a fat finger, but it as always its good to get into the habit of using safer commands.

I would love to get the chance to use bisect one day. Usually when the opportunity comes up, the range of commits I’d have to look through cover large refactors or broken code or tests that make it infeasible, Because I’d have to spend more time than it’s worth altering my local setup to try and isolate the issue.

Note that worktree does not work with submodules. Which IMO is a strong enough reason to never use submodules because worktrees are so useful!