Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)

Sahil Dua [off-list ref] writes:

Ah! I had skipped this reply from Ramsay earlier.

On Tue, Aug 1, 2017 at 1:36 AM, Ramsay Jones
...

quoted

quoted

 I personally do not think "branch --copy master backup" while on
 "master" that switches to "backup" is a good UI, and I *will* say
 "I told you so" when users complain after we merge this down to
 'master'.

I wouldn't normally comment on an issue like this because I am
not very good at specifying, designing and evaluating UIs (so
who in their right mind would listen to me). ;-)

FWIW, I suspect that I would not like using this interface either
and would, therefore, not use it.

Does that mean you'd use it when "branch --copy feature-branch
new-feature-branch" in the case when you would want to start working
on a new branch (to modify or experiment with your current feature
branch) on top of a branch keeping intact all the configuration and
logs?

I am not Ramsay, but your choice of branch names in your question,
i.e. "branch --copy feature new-feature", is what we do not agree
with in the first place, especially when we are *on* the "feature"
branch.

We view "copy A B" as a way to make a back-up of A in B.  I.e. We
want to keep working on A, but just in case we screw up badly, make
a backup copy of A in B, so that we can recover by a "branch --move
B A" later if needed.  So touching B is the last thing we want to do
after "copy A B" operation---hence we do not want to switch to B.

That is not to say that you are wrong to wish to create a new
branch, check it out and start working on it with a single command.
We already have such a command all Git users are accustomed to,
which is "git checkout -b new-feature-branch feature-branch".  

That existing command does not copy things other than the commit
object name from "feature-branch", and I do not think it should by
default.  But I do not think it is wrong to extend it with a new
option (think of it as "checkout --super-b" ;-) to copy other things
like branch descriptions etc.

So from that point of view, your new feature conceptually fits a lot
better to "git checkout", and does not belong to "git branch".  That
is why I do not think "git branch --copy A B" while you are on A
should check out B after creating the copy.