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

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Jun 6, 2017, 07:39 UTC
Message-ID: <CACBZZX5OS_cz_mo4rpd+=DGtyN4SfipGrOXwVHJisv3CywoFaw@mail.gmail.com>
In-Reply-To: <xmqqlgp69ds9.fsf@gitster.mtv.corp.google.com>

On Tue, Jun 6, 2017 at 2:10 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 27 quoted lines

> Sahil Dua <sahildua2305@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'.