Subject: Re: [PATCH/RFC v4 3/3] branch: add copy branch feature implementation

From: Junio C Hamano <[email-masked]>
Date: Tue, 06 Jun 2017 09:10:30 +0900

Sahil Dua <[email-masked]> writes:

> I want suggestions about one logical point raised by Evar.
>
> Let's consider a case that I'm on branch maint and then I do 'git
> checkout master' followed by 'git branch -m feature', it will rename
> master branch to feature. Now if I do 'git checkout -' to go to the
> last branch, it will take me to maint since master branch doesn't
> exist in this case.
>
> Now, for this copy operation - if I'm on branch maint and then I do
> 'git checkout master' followed by 'git branch -c feature', it will
> copy master branch to feature. Now if I do 'git checkout -' to go to
> the last branch, it will again go to maint (according to the current
> implementation). What do you think it should do? Is this the desired
> behavior? Or should it go to master branch since that was the branch
> checked out before copying.
>
> Also, in case this needs to be changed, can someone please point me to
> how it's being handled so that I can change the behavior.

When somebody says "I want to rename my current branch to X", it is
clear that the person wants to end up being on a branch called X.

To me, "I want to copy my current branch to Y" sounds more like "I
want to create another Y that looks just like the current branch,
but I want stay on my current branch".

If you think copy makes @{-1} problematic, perhaps your copy is
doing more than it should (e.g. switching the current branch at the
same time, or something).