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

Ævar Arnfjörð Bjarmason [off-list ref] writes:

On Tue, Jun 6, 2017 at 2:10 AM, Junio C Hamano [off-list ref] wrote:

quoted

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

The way I would use this feature, I'd imagine, would be to stash
away the current state of the branch before I try to do something
potentially stupid, and then recover the original state by reverting
back, i.e.

    $ git branch -c master backup
    ... do silly things to the master branch ...
    ... ok, enough silliness. go back to sane state ...
    $ git branch -M backup master

Having said that, I think it is merely the matter of personal taste
and there is no single "right" definition.  I do not have a strong
feeling either way.

To play devil's advocate, I'd anticipate a criticism, if we take
your interpretation (which I do not _mind_, even though I do not
have strong feeling _for_ it), saying "I just told you to _copy_ it.
If I wanted to check it out, I'd do that myself. Why are you doing
more than I asked, stupid Git." 

I have to say upfront that against such a criticism, I won't defend
your position myself.