On Tue, Jun 6, 2017 at 2:10 AM, Junio C Hamano <gits...@pobox.com> wrote:
> Sahil Dua <sahildua2...@gmail.com> 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".
This would be more useful to me if the semantics were copy & checkout
instead of just copy, since when I'd like to copy branches it's almost
always because I'm on some topic branch and want to create & work on a
new copy of that topic branch.
It would also be consistent with "git branch -m" and easier to
explain, i.e. "git branch -c just like -m except it doesn't delete the
branch name/config you moved away from".
Like with -m, you can still move around random other branches, e.g.:
# While on master
$ git branch -m some-other new-some-other
This will just move some-other to new-some-other without checkout out
new-some-other, it's only when the source name is the same as your
currently checked out branch that you checkout a new branch,
Now, of course the difference is that when you -m your current branch
it doesn't really have a choice of whether to move your checkout as
well (although I suppose it could leave you in a detached HEAD..) so
it *could* be done differently with -c, but the current behavior makes
more sense to me and matches the common case I'd use it for.
> 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).
I think what Sahil is getting at is asking where the @{-N} info is
stored and why this isn't equivalent to:
$ git checkout -b one master
$ git checkout -b two master
$ git checkout master
$ git checkout one
$ git checkout two
$ git checkout - # Goes to "one", not "master"
Which is in analogous flow without this feature that switches to the
last branch, but with "git branch -c" if you were on 'one' and copied
& checked out 'two' doing 'git checkout -' would bring you back to
'master', not 'one'.
