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
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?
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>; firstname.lastname@example.org
Subject: Re: [PATCH v3] checkout: eliminate unnecessary merge for trivial
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.