Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> 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.
