Re: [PATCH 3/3] prevent HEAD reflog to be interpreted as current branch reflog

[Andy Parkins <andyparkins@gmail.com>]

On Friday 2007 February 02 15:13, Nicolas Pitre wrote:
> On Fri, 2 Feb 2007, Andy Parkins wrote:
> > Forgetting about detached heads for the moment,
>
> That is not the way to go about it.  You cannot start forgetting about
> detached heads and come back to it afterwards like an afterthought.

I don't agree.  To avoid confusing people the key thing should be consistency.  
What holds true for HEAD in the non-detached case should hold true for the 
detached case.  Otherwise it's just another variable for the user to 
remember.

> The exact same argument could be said if you did 1300 operations on a
> single branch, say master.  What would master@{yesterday} tell you?
> What will it tell you one minute from now?  Now suppose that you have

It doesn't matter - it will be on the same head, as time ticks by I will at 
least find that master@{yesterday} ticks by linearly too.  That is not the 
case if HEAD@{yesterday} means "whatever HEAD pointed to yesterday".  How am 
I supposed to remember what it pointed to?  Therefore what use is 
HEAD@{yesterday}?

> only one branch and therefore HEAD reflog would be a duplicate of master
> reflog.

You misunderstand, I'm suggesting that reflogging HEAD is not the right thing 
to do.  Asking for HEAD's reflog should be the same as asking for the 
pointed-to-branch's reflog.

Instead, the reflog should be kept for the "unnamed branch", which would jump 
around each time you detached HEAD.

> Answer: it would carry the same kind of confusion as your example above.

I don't agree.  HEAD is always "the branch I'm on now", even when it's 
detached it's pointing at the branch I'm working on.  It just happens that 
that branch has no name.

> Then simply use @{15 minutes ago}.  You'll even save yourself some
> typing!  It is not like if you have to type HEAD for most operations

I'm not worried about the typing, or about the functionality.  I think that 
the functionality will be there in either of the proposed cases.  I am 
arguing which is the least confusing.  The amount of typing should certainly 
not be a factor in this case.

> anyway since HEAD is the likely default in most cases.  So you may even
> forget that the HEAD entity exists and be just fine.

Yep; in my scenario that's true.  One could completely forget about HEAD.  In 
your scenario that isn't the case, because I need to remember that when I'm 
detached HEAD suddenly gets special powers to tell me about the detached 
movements.

> But HEAD is still a moving pointer and we might want to know that it
> switched from one branch to another at some point.  And the only way for
> that to be sensible is by having a separate reflog for HEAD that is the
> exact log of every operations you perform regardless of the actual
> branch you might be on.

I agree.  I am arguing about nomenclature.  There is no dispute that /that/ 
reflog (or equivalent) should exist.  However, I don't believe it should 
be "the log of HEAD" it should be "the log of the unnamed branch".


> HEAD _does_ get detached.  It becomes loose in the air.  It doesn't drag

Well, we're talking semantics now.  HEAD becomes detached from a branch, but 
it certainly isn't floating.  It points at a particular point in the 
repository.

HEAD is always a symref (despite what you say); it's just that when HEAD is 
detached from all branches, there is no ref for it to point at, so we store 
the ref in the file called HEAD.  It's analogous to pointers in C:

  HashType hash;
  HashType *ref;
  HashType **HEAD;

By sometimes treating HEAD as a ref, you break the model.

> pointer with it.  And everything you do on top of a detached HEAD will
> be forgotten as soon as you leave it (and the eventual reflog for HEAD
> expires) if you don't attach it somehow with a tag or a new branch.
> There is no notion of a virtual branch at all, not technically, not
> conceptually either.

I disagree that there is no virtual branch.  That is what HEAD is when it is 
in detached mode.  It looks just like a ref - HEAD holds a hash, refs hold a 
hash - how is that not a virtual branch?  I used the word "virtual" only 
because it is not stored in refs/ and vanishes when you move back to a real 
branch.  Just because the virtual branch is stored in HEAD, I think it is 
dangerous to thing of HEAD as being the thing that is logged - it is this 
virtual branch that should be logged because that branch is always there and 
can be tracked through time as a discrete entity.  If you track HEAD itself, 
then sometimes it will hold the same as a branch reflog, sometimes it will 
hold unique data.

Perhaps this is just a product of my warped mental model of git.  Obviously 
you chaps who do the actual work get final say.  Take the above with my usual 
two cents of "I can't be sure of what I'm talking about" :-)




Andy
-- 
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@gmail.com