Ævar Arnfjörð Bjarmason <ava...@gmail.com> writes:

> 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           |
> |----------------------------+--------------+-------+---------+-----------------+-------------|

I actually consider "branch" to *never* invoking a checkout.  Even
when "git branch -m A B" happens to be done when your checked out
branch is A and you end up being on B.  That is not a "checkout".

Really from the end-user's point of view that is not a checkout.
The user renamed the branch A and the same conceptual entity, which
is a branch, is now called B.  If that branch was what was checked
out (IOW, if that branch was what would be grown by one commit if
the user did "git commit"), then now that branch's name is B.  It is
natural if you ask "symbolic-ref HEAD" what branch is checked out
after renaming A to B (and A happened to be what was checked out),
the answer chould be B.

It's like the city you live in changed the name of the street your
house is on.  You do not call movers, you do not do anything, but
your address changes.

> 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           |
> |-------------------------------------------+--------------+-------+---------+-----------------+-------------|

You are talking backwards.  I do not want "branch -c A B", even when
A happens to be what is checked out, to check out branch B.  You and
Sahil were who wanted to check out branch B while doing so, and I
just tried to guess why you two wanted to have such a behaviour that
did not make much sense to me.  And my guess was "perhaps they want
a way to create a new branch starting from another branch, and check
it out, and do so in a single end-user operation".  

I am not particulary interested in such an operation; in my guess,
you two are.  And the "super-b" thing was a suggestion to you two:
If you so desperately want such an operation, then don't make
"branch --copy A B" that operation.  Such an operation better fits
in "checkout", not "branch".

If you are not interested in such an operation, then that is fine.
Do not add the "super-b" mode to "checkout".

But I won't defend a "branch --copy A B" that checks out B when
users and other people like Ramsay think that such a behaviour is
illogical, because I do think it is, too.

Reply via email to