> The key idea is to have a workflow in mind, and steer users towards that workflow. Because sure, you can ask user if they want to "delete a local branch, and then just get it recreated when you pull again".. but that's terrible idea. Why would you want to do this _ever_ as part of any regular workflow?
I've recently tried to guide someone to fix their bad branching strategy, and after a few of their bad attempts, just suggesting they remove their local branch and then refetch it from the published repo instead (just imagine how easy it is to figure out what commands-people-have-blindly-typed-in-from-the-internet have done, and then reverting that with git).
Going back to a known good state is the most common of all debugging tools (also part of more advanced tricks like bug bisection search — interestingly also present as `git bisect`), and with it being too easy to mess up your local repo, going back to a remote that's "clean" is sometimes the fastest approach.
> The key idea is to have a workflow in mind, and steer users towards that workflow. Because sure, you can ask user if they want to "delete a local branch, and then just get it recreated when you pull again".. but that's terrible idea. Why would you want to do this _ever_ as part of any regular workflow?
I've recently tried to guide someone to fix their bad branching strategy, and after a few of their bad attempts, just suggesting they remove their local branch and then refetch it from the published repo instead (just imagine how easy it is to figure out what commands-people-have-blindly-typed-in-from-the-internet have done, and then reverting that with git).
Going back to a known good state is the most common of all debugging tools (also part of more advanced tricks like bug bisection search — interestingly also present as `git bisect`), and with it being too easy to mess up your local repo, going back to a remote that's "clean" is sometimes the fastest approach.