On Fri, Mar 15, 2019 at 3:19 PM Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote: > > On Wed, Mar 13, 2019 at 2:36 PM Eckhard Maaß > <eckhard.s.maass@xxxxxxxxxxxxxx> wrote: > > On Fri, Mar 08, 2019 at 04:57:48PM +0700, Nguyễn Thái Ngọc Duy wrote: > > > Similar to automatic detach, this behavior could be confusing because > > > it can sometimes create a new branch without a user asking it to, > > > especially when the user is still not aware about this feature. > > > > > > In the future, perhaps we could have a config key to disable these > > > safety nets and let 'switch' do automatic detach or dwim > > > again. But that will be opt-in after the user knows what is what. For > > > now give a short option if you want to use it often. > > > > As I am late to the patch series (sorry!), has there been already any > > discussion on that? In my experience, people get confused with detached > > HEAD state quite often, whereas the automatic creation of a local branch > > is no problem. > > This statement does a good job of articulating my (unspoken) response > to this patch. Whereas a detached HEAD might be scary and confusing to > newcomers, and difficult for them to recover from, automatic creation > of a DWIM'd local branch doesn't seem so problematic (if at all). > > With git-checkout, it's very easy to accidentally get into a detached > HEAD state, so it makes some sense to protect newcomers, by default, > from that accident in git-switch. However, auto-creation of a new > local branch is not, for a couple reasons, nearly so weighty a matter. > First, in many cases it may be less likely to happen since it requires > presence of a corresponding remote tracking branch. Second, it's > intuitively easy to recover from it: when git-switch reports that it > created a new branch, though perhaps surprising, the user would > naturally know to look for a command to "delete a branch". > > And, unlike a detached HEAD, which newcomers may mistakenly believe > lead to irretrievable loss of work, an unexpected branch creation > carries no such penalty, perceived or real. I can't remember the last time it was discussed, but part of the reasons I chose to default --no-guess is because completion will be a lot less noisy. But that's a very personal preference. I will switch to --guess as default no problem (unless someone jumps in and screams NOOO of course). Please don't hold back when you find something not quite right. At least now I can fix it. Either that or by the time it's released, the Internet will blame me for adding yet another confusing git command :P -- Duy
