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

On Friday 2007 February 02 15:13, Nicolas Pitre wrote:

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.

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}?

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.

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.

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.

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.

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".

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.

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