Re: What's cooking in git.git (topics)

Nicolas Pitre [off-list ref] writes:

On Sat, 27 Jan 2007, Junio C Hamano wrote:

quoted

* np/dreflog (Fri Jan 26 17:26:11 2007 -0500) 8 commits

I might be partial of course, but I think it is preferable to merge it 
before 1.5.0 since this causes a behavior change.  Currently HEAD@{n} 
inherits the reflog of the branch HEAD is currently on.  With this patch 
serie HEAD@{n} is the true reflog for HEAD regardless of where it is now 
and where it has been independently of the current branch.  Of course I 
consider the later behavior to be more sensible and it might be a good 
idea to give it to 1.5.0 users at the same time as the detached head 
support rather than creating a behavior change later on when reflogs are 
more popular.

My understanding of the situation after your patch (disregarding
the problem that prune and friends may happily break the logs
for detached HEAD), is that if you say "git show HEAD@{...}",
while on a branch, it looks at the log of the current branch but
while on a detached HEAD it shows the log from .git/logs/HEAD.
I have a feeling that this would be confusing.  Ideally, while
on a branch, say 'master', these two should behave differently:

	$ git show 'master@{5.minutes.ago}'
        $ git show 'HEAD@{5.minutes.ago}'

The former talks only about where the tip of that particular
branch were while the latter also should tell you on which
branch you were on.

But then that raises two new problems:

 - We always said: 'HEAD' means the same thing as your current branch.
   This is not true anymore.

 - You do not record which branch you were on in the log for
   HEAD itself (it is merely a dup), so while the latter would
   report which commit you were at, you cannot tell which branch
   you were on (or if your head was detached).

While I am sure that prune problem is solvable, I have a feeling
that it would take some time to iron out the semantic issues
like the above (and I suspect there might be even more).