On 07/08/2017 23:25, Igor Djordjevic wrote:
> 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).
All this said, having you mentioning the two argument version:
> $ git checkout master
> $ git branch -m topic avar/topic
... exactly proves the point that "git branch -m" is not expected to
involve a checkout, even from implementation perspective. It`s just a
consequence of needing to update the (now obsolete) reference HEAD
points to (only) when the branch we`re renaming (moving) is the one
that is currently checked-out.
> Yeah it's not something I'm interested in or have a use-case for,
> although I think in the same way we have -t for checkout it might be
> sensible to have e.g.:
>
> $ git checkout -b topic-2 -c topic -t origin/master
>
> Where the new -c or --config-from would mean "...and get the config from
> 'topic'". Such a name would probably be less confusing than
> --super-b[branch?] which to be implies some ongoing hierarchical
> relationship.
This, on the other hand, sounds sensible, staying true to the
existing logic. In the same manner you can do either:
$ git branch topic -t origin/master
$ git checkout topic
... or shorter equivalent:
$ git checkout -b topic -t origin/master
..., you should be able to do:
$ git branch -c topic topic-2
$ git checkout topic-2
..., or equivalent:
$ git checkout -b topic-2 -c topic
..., where "-c" would follow the same (or similar) logic as "-t" does
now, as you already pointed out :)
p.s. That said, is `git checkout -b topic-2 --move topic` being
missed now...? :P That one would/could/should actually be expected to
move (rename) the branch *and* check it out, no matter if HEAD
currently points to it or not.
Regards,
Buga
