Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)

[Igor Djordjevic <igor.d.djordjevic@gmail.com>]

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