Sahil Dua <sahildua2305@xxxxxxxxx> writes: > Ah! I had skipped this reply from Ramsay earlier. > > On Tue, Aug 1, 2017 at 1:36 AM, Ramsay Jones > ... >>> 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.
