Nicolas Pitre <nico@xxxxxxx> writes:
> On Sat, 27 Jan 2007, Junio C Hamano wrote:
>
>> * 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).
-
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