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

On 03/08/17 22:07, Junio C Hamano wrote:

Sahil Dua [off-list ref] writes:

quoted

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.

I couldn't have said this better. ;-)

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

Indeed, I wouldn't think of doing anything else. (That may be
because I've been using git too long, of course).

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.

Hmm, I've never felt the lack of copying any attributes from
the origin branch. So, I'm not convinced a "--super-b" is needed
(but if other people feel the need, then why not).

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.

I agree (but lukewarm on the --super-b idea). :-D

ATB,
Ramsay Jones