On Thu, Aug 03 2017, Junio C. Hamano jotted:
> 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.
We've talked how this UX should look before on-list. Rather than
re-hashing the arguments I had before I thought it was useful to present
it as a table. Here's how the patch looks now:
|----------------------------+--------------+-------+---------+-----------------+-------------|
| cmd | creates new? | moves | copies? | ...with config? | checks out? |
|----------------------------+--------------+-------+---------+-----------------+-------------|
| branch <name> | Y | N | N | N | N |
| checkout <name> | Y | N | N | N | Y |
| checkout -b <name> <start> | Y | N | Y | N | Y |
| branch -m <name> | Y | Y | N | Y | Y |
| NEW: branch -c <name> | Y | N | Y | Y | Y |
|----------------------------+--------------+-------+---------+-----------------+-------------|
In previous discussion my understanding was that you preferred the
following (as an ad-hoc word-diff)
|----------------------------+--------------+-------+---------+-----------------+-------------|
| cmd | creates new? | moves | copies? | ...with config? | checks out? |
[... stuff above this point is the same ...]
| NEW: branch -c <name> | Y | N | Y | Y | {-Y, +N} |
|----------------------------+--------------+-------+---------+-----------------+-------------|
I.e. have "branch -c <name>" but just make it not checkout the new
thing. What you're describing above sounds to me like:
|-------------------------------------------+--------------+-------+---------+-----------------+-------------|
| cmd | creates new? | moves | copies? | ...with config? | checks out? |
[... stuff above this point is the same ...]
| branch -m <name> | Y | Y | N | Y | Y |
[... so is branch -m but included for context ...]
| NEW: checkout --super-b -b <name> <start> | Y | N | Y | Y | Y |
|-------------------------------------------+--------------+-------+---------+-----------------+-------------|
As (IIRC) noted in some earlier mail of mine: I don't disagree with what
you're suggesting, and this horror of a checkout/branch UX is not
something anyone would have made from scratch with the benefit of
hindsight.
However we have 2x commands that checkout branches now and do some
combination of creating, moving and copying them (with & without
config).
I think given that we have "branch -m <name>" already introducing a
"branch -c <name>" that does exactly the same thing except "leaves old
name behind" was the simplest thing both in terms of explaining it to
users and to implement, since all the code except removing the old
config section will be shared with "branch -m".
But having this "checkout --super-b -b <name> <start>" would make the UX
even uglier, since now we have a command that does 99% of what "branch
-m <name>" does, but is invoked differently.
I think this end state would make more sense:
|----------------------------------------+--------------+-------+---------+-----------------+-------------|
| cmd | creates new? | moves | copies? | ...with config? | checks out? |
|----------------------------------------+--------------+-------+---------+-----------------+-------------|
| branch <name> | Y | N | N | N | N |
| checkout <name> | Y | N | N | N | Y |
| checkout -b <name> <start> | Y | N | Y | N | Y |
| DEPRECATED (WARNS): branch -m <name> | Y | Y | N | Y | Y |
| NEW: checkout --move -b <name> <start> | Y | Y | N | Y | Y |
| NEW: checkout --copy -b <name> <start> | Y | N | Y | Y | Y |
|----------------------------------------+--------------+-------+---------+-----------------+-------------|
I.e. let's just move this functionality to "git checkout" and deprecate
"branch -m" (which we could alias to begin with to checkout --move".
I think *that* would make sense, but not the half-assed solution of
moving a new checkout command to git-checkout while we have an analogous
checkout command in git-branch without being deprecated.
