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

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

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