I understand the reluctance to change the existing behavior of the "git checkout -b <new-name>" command.
I see this as a tradeoff between taking advantage of the muscle memory for the existing command and coming up with a new shortcut command and training people to use it instead. The fact that all the use cases we've observed and all the git test cases actually produce the same results but significantly faster with that change in behavior made me hope we could redefine the command to take advantage of the muscle memory. That said, you're much more on the frontline of receiving negative feedback about doing that than I am. :) How would you like to proceed? Ben -----Original Message----- From: Junio C Hamano [mailto:gits...@pobox.com] Sent: Monday, September 19, 2016 1:04 PM To: Ben Peart <peart...@gmail.com> Cc: pclo...@gmail.com; Ben Peart <ben.pe...@microsoft.com>; git@vger.kernel.org Subject: Re: [PATCH v3] checkout: eliminate unnecessary merge for trivial checkout Junio C Hamano <gits...@pobox.com> writes: >> "git checkout -b foo" (without -f -m or <start_point>) is defined in >> the manual as being a shortcut for/equivalent to: >> >> (1a) "git branch foo" >> (1b) "git checkout foo" >> >> However, it has been our experience in our observed use cases and all >> the existing git tests, that it can be treated as equivalent to: >> >> (2a) "git branch foo" >> (2b) "git symbolic-ref HEAD refs/heads/foo" >> ... > > I am still not sure if I like the change of what "checkout -b" is this > late in the game, though. Having said all that. I do see the merit of having a shorthand way to invoke your 2 above. It is just that I am not convinced that it is the best way to achieve that goal to redefine what "git checkout -b <new-name>" (no other parameters) does.
