On Mon, Aug 07 2017, Igor Djordjevic jotted:
> 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.
Yeah, I think that's a fair summary. Also I didn't mean to de-rail this
whole thread on what "checkout" really means, just explain what I meant
with previous comments, since there seemed to be confusion about that.
>> 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.
It's not *required* we could do one of three things:
1) Do what we do now, i.e. rename the branch/reflog & check out the new
name.
2) Rename the branch/reflog and checkout HEAD^0, i.e. say "the branch
is now elsewhere, but we haven't moved your commit".
3) Just not run replace_each_worktree_head_symref() which would end up
on a branch with no commits, i.e. an orphan branch.
Now, I think 2 & 3 are pretty nonsensical and wouldn't ever propose we
should do that, but it's illustrative that #1 is not some required
inevitability in terms of explaining what's happening with the new name
being checked out (i.e. HEAD being updated).
>> Documentation for "git-checkout" states that it is used to "*Switch
>> branches*...[snip]", and that is not what happens here.
That's just the summary at the top but not the full story of what
git-checkout does. E.g. you can checkout a bare SHA1 which is not
switching branches, or a tag or whatever.
>> 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.
Kind of, it's also worthwhile to think about that in some sense no
switch would be performed as far as the user is concerned by taking
option #2, i.e. we'd be in the same working tree / you could still make
commits.
You just couldn't make new commits on your "master" which is now called
"topic" and get new commits on "topic". I think it makes sense to do
that, but again, it's illustrative that it's not inevitable for
discussing the implementation.
>> 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.
I've yet to see a good real-world analogy of "DAG with labels", which is
all git really is, that doesn't break down at some point. Trees are
probably the best comparison, but even that breaks down in the face of
branch merges or even merges of entirely unrelated trees.
So it's probably pointless to discuss this tangent any further, I don't
think it helps with deciding what to do about this new -c construct.
>> 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).
Yes I agree that this has little to no impact on what's happening for
the user, I've merely been discussing "checkout" in the terms of what's
happening under the hood here.
> 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.
Hrm, I think you're confused about what this example does. For the sake
of avoiding confusion let's stop talking about checkout and just talk
about updating the HEAD.
The point of that example is to show that the HEAD is only updated by
git branch [-m|-c] if the branch being moved/copied is the branch you're
currently on.
Here the user just checked out master and then moved an unrelated topic
to avar/topic, that just manipulates the ref store & config, and won't
touch the HEAD.
The reason I'm mentioning that example (and talking about a "subset") is
that amending git-checkout to do some of what this new "git-branch -c"
option would do would only cover a subset of what it does, since both -m
and -c are two-mode options in the sense that some of the time they
manipulate the refstore and the HEAD, and some of the time only the
refstore.
>> 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:
To continue the explanation above, yeah it's sensible, but I'm pointing
out that it's *also* sensible, i.e. whatever mode git-checkout has for
"let's create a branch with the same start point & config as [some other
branch]" it's always going to be complimentary but not a replacement for
git branch [-m|-c], since [-m|-c] has a mode for doing that without
doing any checkout whatsoever, just manipulating the refstore.
> $ 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
