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@xxxxxxxxx
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html