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?


-----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 

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.

Reply via email to