Duy Nguyen <pclo...@gmail.com> writes: >> >> OK. Is "auto-vivify the named branch based on a remote-tracking" >> also rejected, as it is a confusing behaviour that is a too subtle >> and implicit, just like the detaching head is, and require --guess >> or sticking to 'git checkout'? I think it should. > > This touches the "remote" concept which I think is another confusing > thing for new people (your "master" is not the same as the server's > "master", aka origin/master) and perhaps this dwim thing helps. > Frankly I don't do dwim much so I don't know if it's that often used.
I actually think a user who sees a DWIM without understanding what the user wants to do would perceive magic that sometimes works and sometimes does not, and some other times it does a random thing that the user does not even understand what is going on. And such a random magic that sometimes works, even if the "sometimes" is "most of the time", say 85% of the time, would not help user form the right mental model. "git checkout master~2" that DWIMs to "git checkout --deatch master~2", but does totally different thing when "git checkout master" is given, leaving the user confused "what is so different between these two?". Until the user realizes 'master' can serve both as a branch name and a name for a commit object, while master~2 can only be a name for a commit object and is not a branch name, the behaviour of the command will stay to be mysterious and DWIMmage would not help user form the right mental model. I earlier said that I agree with your decision to leave the implied form out of switch-branch for exactly that reason. The behaviour falls into the same category as "git checkout frotz" that DWIMS to "git checkout -b frotz -t remotes/origin/frotz", which also is mysterious until the user understands your 'master' is unique and is different from 'master' to everybody else, I would think.
