On 06/08/2017 22:26, Ævar Arnfjörð Bjarmason wrote: > On Sat, Aug 05 2017, Junio C. Hamano jotted: >> 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". > > I think we just have a different mental model of what "checkout" > means. In my mind any operation that updates the HEAD to point to a new > branch is a checkout of that branch.
If I may, from a side-viewer`s point of view, it seems you`re thinking in low-level implementation details, where what Junio describes seems more as a high-level, conceptual/end-user`s point of view. Needing to update HEAD reference once we "rename" a branch, too, what you consider a "checkout", seems to be required only because branch name _is_ the branch reference in Git, so we need to update HEAD to point to a new/renamed branch reference -- but it`s still the same branch, conceptually. Documentation for "git-checkout" states that it is used to "*Switch branches*...[snip]", and that is not what happens here. Implementation-wise it does because we can`t do it differently at the moment, but in user`s eyes it`s still the same branch, so no switch is made as far as the user is concerned. In a different implementation, where branches would have permanent references other than their names, no HEAD update would be needed as the reference would still be the same, no matter the name change, making the `git branch -m` situation clear even from your standpoint, I`d say. >> 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. > > Yeah I see what you mean, although this analogy rapidly breaks down when > you poke at it as shown above. My house (a sha1) can be on any number of > streets and new ones can be added/removed all the time without changing > where my house is at. I may be missing something, but I find the house/address analogy a good one, actually, as I understood that "house" resembles a branch reference HEAD is pointing to, not a sha1. Even further, and that might be the point of confusion, "house" seems to be more like a "permanent branch reference" I mentioned above, where your address can change (branch being renamed), but you would still be in the same house (HEAD would still point to the same permanent branch reference). If you move to another house, only then would HEAD change to point to another (permanent) branch reference (a different house), and that would be a checkout. Yes, it`s not really how it works from the inside, but I think that`s irrelevant for the end-user experience :) > So it's just a way to get something exactly like -m except the "move && > checkout" logic is changed to "copy && checkout". Again, it seems the "checkout" part of "move && checkout" you`re talking about is a user-wise unnecessary implementation detail. For the user, it`s just a simple "move", staying on the same, but renamed branch, thus no branch switching occurred (no "checkout", as per documentation). Regards, Buga
