Philip Oakley <philipoakley@iee.email> writes: > On 22/11/2020 10:21, Sergey Organov wrote: >> Junio C Hamano <gitster@xxxxxxxxx> writes: >> >>> Sergey Organov <sorganov@xxxxxxxxx> writes: >>> >>>> To me "not on a branch [tip]" is also confusing, as in fact you are, as >>>> is easily seen after you perform a few commits, and now HEAD points >>>> directly to the tip of the branch (that has no other references). >>> Aren't you confused about what "on a branch" means? >> I believe I'm not. > > Isn't this one of those "implementation detail" viewpoint arguments, > combined with some incompleteness in various places. > > From a naive english user perspective , 'on' a branch can also mean > anywhere along a branch and not just at the tip. Being at a commit along > a branch can be tricky to appreciate (that on/at distinction isn't > immediately obvious..) >> >>> After either of these two operations, your HEAD may point at the >>> same commit, but the former is on a branch (the master branch), and >>> the latter is not. >>> >>> git checkout master >>> git checkout master^0 >>> >>> The difference between these two states does *NOT* come from which >>> commit HEAD points at. >> Sure. > From an implementation perspective one can go two ways, and we tell the > user which way we went, even though, ultimately, we look at the same > commit. AFAIU, the only difference is that HEAD points to the commit directly in the case of "detached HEAD", while it points to the commit indirectly through the branch reference in the usual case. > > Though, for an unborn branch we don't have a null commit value (c.f. > empty tree) to help in being 'detached at nowhere'. We can pretend we have a null commit for the sake of regularity, even though Git implementation has none. Actually, it looks like a few things would be easier if Git got the "Adam" commit that is the ultimate final parent of everything in the first place, but it didn't. >> >>> The difference comes from what happens when you make a new commit >>> starting from that state. The former (i.e. you are on a branch) >>> grows the branch. >> Sure. >> >>> The latter (i.e. you are not on a branch) does not grow any branch. >> That's one way of looking at it, resulting in this "detached HEAD" >> thingy that is too technical for the git user proper, I think. Moreover, >> it immediately raises the question: if it doesn't grow any branch, /what/ >> does it grow? >> >> Another way of describing it, that I prefer, is that you /are/ on an >> /unnamed/ branch and new commits grow this particular /unnamed/ branch. >> No need not only for "detached", but even for "HEAD" to be known to the >> user to get the idea, I think. > I don't think we can start like this and continue with a commit on top > of the orphaned 'unnamed' branch. (Not tried it though..) I rather believe we can, no problems, and that's why "detached HEAD" behaves exactly as unnamed branch would. To make it obvious "detached HEAD" is in fact a subset of the usual case, imagine that "detached HEAD" is rather first implemented by pointing to a branch reference with a hidden name that in turn points to the commit, and then this "incognito branch reference" is optimized-out as being invisible anyway, so HEAD now points to the commit itself. -- Sergey Organov
