"Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes:
> Nicolas Pitre <nico@xxxxxxx> wrote:
>> 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".
-
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