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

"Shawn O. Pearce" [off-list ref] writes:

Nicolas Pitre [off-list ref] wrote:

quoted

The work in progress to enable separate reflog for HEAD will make it
independent from reflog of any branch HEAD might be pointing to. In
the mean time disallow HEAD@{...} until that work is completed. Otherwise
people might get used to the current behavior which makes HEAD@{...} an
alias for <current_branch>@{...} which won't be the case later.

I happen to really like the fact that HEAD@{...} is an alias for
<current_branch>@{...}.

It is usually easier to type.

But now that HEAD will soon be getting its own reflog, I guess I
better relearn how to type <current_branch>.  :-)

One thing that is certain is that master@{...} will mean the
same thing no matter what happens to Nico's series -- it talks
about where the tip of that particular branch was at any recent
time.  Right now HEAD@{...} happens to talk about "the current
branch" (and only the current branch) -- Nico's patch would
change the semantics when/if it is merged.

So I would not mind making sure that our documentation talks
only about specific branch's reflog for now (git grep 'HEAD@{'
in Documentation directory luckily hits nothing) but am a bit
reluctant to remove the already useful shorthand from a working
system.

Although from the consistency point of view, HEAD reflog to
follow swicthing branches like Nico's patch aims for (but not
implements fully yet) makes perfect sense, I still am somewhat
doubtful about it being actually useful in practice.  Even if we
assume it is useful, I think forbidding people from saying
HEAD@{...} right now only because the new semantics is
unimplemented yet feels wrong.  If you use only one branch,
there is no difference between the reflog of master and HEAD
today, without waiting for that "reflog on HEAD".