Perhaps we should use @{...} to refer to reflog for HEAD, or use
yet another special notation?

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git


-

[ message continues ]

Hi,


No.

IMHO "bla@{yesterday}" should give you what "bla" pointed to, yesterday. 
In that sense, the proposed reflog on "HEAD" makes perfect sense.

I am not quite sure what I need most, the reflog for "HEAD", or that for 
my current branch. I guess it is the latter, so I am okay that 
"@{yesterday}" should mean the current branch, yesterday.

Ciao,
Dscho

-

[ message continues ]

Since HEAD is a synonym for "current branch" everywhere else in git,
while .git/logs/HEAD will be a log of detached HEAD (plus branch
switches, I guess), I think the following makes perfect sense:

  "HEAD@{yesterday}" = current branch, yesterday
  "@{yesterday}"     = detached head (no branch), yesterday


Just my 2c

--
larsh
-

[ message continues ]

I'd vote for this too.  It's the only logically consistent view.

HEAD is a symbolic reference, it's a way of referring to a real branch by 
another name.  HEAD@{} should be the same as branch@{} to be consistent.

Forgetting about detached heads for the moment, imagine that yesterday I did 
lots of bouncing around on branches, around 1300 (although I wouldn't 
remember the exact time).  Oh look, it's about 1300 now.  What then is
HEAD@{yesterday} going to tell me?  What will it tell me one minute from now?  
It would be the most confusing operation in the world; I'd have to remember 
which branch I had checked out and what time I checked it out.

I really don't want to be able to answer the question what branch did I have 
checked out 15 minutes ago.  I do want to ask where was my current branch 15 
minutes ago.

Then of course, it's perfectly reasonable to treat the detached HEAD as 
meaning that the symref HEAD was pointing at a kind of virtual branch - this 
is a branch that isn't in the refs directory but is reflogged.  Other than 
that it's no different from any other branch.

Any notation would do I think, @{} is as good as any other.  In fact, if we 
used the name "unnamed branch" instead of "detached head", the notation @{} 
is perfect.  (Actually I think unnamed branch is a much better term than 
detached HEAD, because HEAD is never detached - it must point at something)



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

[ message continues ]

HEAD is _NOT_ a symbolic reference.  It _may_ happen to be a symbolic 
reference, but it _may_ happen to not be.

And please see my previous email for more arguments.


Nicolas
-

[ message continues ]

That is not the way to go about it.  You cannot start forgetting about 

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 
only one branch and therefore HEAD reflog would be a duplicate of master 
reflog.


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 
anyway since HEAD is the likely default in most cases.  So you may even 
forget that the HEAD entity exists and be just fine.

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 

HEAD _does_ get detached.  It becomes loose in the air.  It doesn't drag 
any 
branch 
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.


Nicolas
-

[ message continues ]

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 

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 

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 

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 

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 

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 

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 

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;


I disagree that ...
[ message continues ]

hopefully, yes!  Having to know "uhm, that time I was detached, oh, no, t=
hat was a ref" is the variable.  The reflog we are talking about, no matt=
er how it might be called or how its symbol is should track where my inde=
x wanders.  which is called HEAD, I think (sorry, I'm quite new to git).

So, to make it clear, when I do this:

git checkout master
git checkout build
git checkout master~1
git checkout dbcca21
git checkout master
hack && git commit -a

then i expect the "reflog to be named" to follow *exactly these steps:

master, build, master~1, dbcca21..., master, newmaster

and _not_ just

master~1m, dbcca21...

cheers
  simon

--=20
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low =E2=82=AC=E2=82=AC=E2=82=AC NOW!1  +++=
      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \

[ message continues ]

I'm sorry but I can't help the fact that I think it's your argument that 


It is there precisely to tell you what it pointed to yesterday, and how 
you happened to get there if you care.

If you want a particular branch reflog you just name it explicitly.

If you want the current branch's reflog you use @{...}.



That just has no logic.  HEAD is a pointer that can move inside 
branches, across branches, and even outside of any branches.  Remember 
that reflog is a "log", so the most obvious thing to do is simply that: 
logging operations affecting the HEAD pointer, _including_ the switching 
between branches, should be logged.

Having HEAD@{} named explicitly but changing meaning 
entirely depending on an implicit state (the current branch) when the 
explicit name doesn't change _is_ inconsistent in my book.  This is why 
there is now @{...} (no explicit name) that means the current branch 

Whatever.  But you must admit that, with that same logic, the HEAD 
reflog should always be a log of "the branch you were on" at the time it 
has been recorded.

But because @{...} carries no name information, it has no _explicit_ 
meaning and therefore can refer to whatever reflog your current branch 
is at the moment.  It may change universe when you change branch just 

No.  HEAD is never special.  HEAD@{} is a log of all values HEAD had in 
the past.  So HEAD@{5} will _always_ give you the fifth last position 
your checked out tree was at, regardless if it happened to be  on branch 
x or branch y or detached.  The same logic goes for master@{} which will 
_always_ return the previous values master might have had.

And because people want a shortcut to mean the reflog of the current 
branch then we use @{} without any explicit name.  This way the reflog 
for @{} being annonymous can change at will depending on the current 

OK...  If what you want is an explicit "detached head" reflog then let's 
just create one!  But that doesn't eliminate the need for a separate 
HEAD ...
[ message continues ]

In the counterproposal, we have

   "HEAD@{yesterday}" = where HEAD was at, yesterday
   "@{yesterday}"     = current branch, yesterday

The side with patch wins (well, the one that can convince Junio).
But serously, that decision is work for maintainer.
-- 
Jakub Narebski
Poland
-

[ message continues ]

+1 (actually not only "detached head", but "where my workdir was", includ=
ing named branches as well)

--=20
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low =E2=82=AC=E2=82=AC=E2=82=AC NOW!1  +++=
      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \

[ message continues ]

okay, I take this back and claim the opposite:

+1 for

@{..} =3D current branch
HEAD@{..} =3D log of where HEAD was, detached or not detached, no matter

cheers
  simon

--=20
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low =E2=82=AC=E2=82=AC=E2=82=AC NOW!1  +++=
      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \

[ message continues ]

No it doesn't.

HEAD is a moving pointer.  Sometimes it means the current branch, 
sometimes it doesn't.

So HEAD is _NOT_ a synonym for "current branch" everywhere already.

And it is really nice to reflog the switching between branch which makes 
sense only if HEAD has a reflog of its own.

If I want to know where HEAD was yesterday, then the only way to get to 
this info is with a separate reflog for HEAD.  IF HEAD was a synonym for 
the current branch then it is impossible to know where HEAD was 
yesterday because you only get the info about where the current branch 
was yesterday.  But it is all possible that the yesterday's current 
branch wasn't the same as today's current branch.


Nicolas
-

[ message continues ]

All true. I guess I'm just used to thinking about HEAD as a pointer to
the current branch, and that was the reasoning behind my proposal.

But with a detached HEAD this is no longer true, and you end up being right :)

Sorry for the noise

--
larsh
-

[ message continues ]

Hi,


Okay, so you say "HEAD@{yesterday}" does _not_ give you what HEAD pointed 
to yesterday, but "@{yesterday}" does?

Instead "HEAD@{yesterday}" looks up what HEAD points to _now_, and _then_ 
goes back to yesterday, finding out what that particular branch pointed to 
then, _regardless_ what HEAD was then?

Oh my, that's convoluted.

Ciao,
Dscho

-

[ message continues ]

Depends on your point of view:

  HEAD: 1) noun.  Synonym for the branch I am currently on.
  HEAD: 2) noun.  Synonym for the commit I am currently on.

Now that we can detach our HEAD anytime we want, I'm in the
latter camp, and your (Dscho's) meaning for HEAD@{yesterday} and
@{yesterday} makes perfect sense.

But I suspect most Git users are still in the former camp, as they
haven't been exposed to the process (or need, or desire) to detach
their HEAD...

-- 
Shawn.
-

[ message continues ]

Hi,


HEAD: 3) noun. The tip of the current branch.

But has _nothing_ to do with a detachable HEAD.

Once people know what HEAD is, they do

	git show HEAD

to see what the tip of their current branch looks like. Now, read out 
aloud "HEAD@{12:00.pm.yesterday}". Yes, that's right. It says "HEAD at 
noon yesterday".

I mean, it's really easy to see what HEAD is good for. If your head 
automatically resolved HEAD to "the current branch, right now, even if I 
am talking about another time", I find it convoluted.

That's all.

Ciao,
Dscho

-

[ message continues ]

Well, luckily Nicolas got me thinking straight again:

  http://article.gmane.org/gmane.comp.version-control.git/38507

-- 
larsh
-

[ message continues ]