Patrick Steinhardt <ps@xxxxxx> writes:
>> Even though it may feel wrong to successfully resolve foo@{0} when
>> reflog for foo does not exist at the mechanical level (read: the
>> implementors of reflog mechanism may find the usability hack a bad
>> idea), I suspect at the end-user level it may be closer to what
>> people expect out of foo@{0} (i.e. "give me the latest").
>
> Hum, I dunno. I don't really understand what the benefit of this
> fallback is. If a user wants to know the latest object ID of the ref
> they shouldn't ask for `foo@{0}`, they should ask for `foo`. On the
> other hand, if I want to know "What is the latest entry in the ref's
> log", I want to ask for `foo@{0}`.
The usability hack helps small things like "List up to 4 most recent
states from a branch", e.g.
for nth in $(seq 0 3)
do
git rev-parse --quiet --verify @$nth || break
git show -s --format="@$nth %h %s" @$nth
done
vs
for rev in HEAD @{1} @{2} @{3}
do
git rev-parse --quiet --verify "$rev" || break
git show -s --format="$rev %h %s" "$rev"
done
by not forcing you to special case the "current".
Ideally, "foo@{0}" should have meant "the state immediately before
the current state of foo" so that "foo" is the unambiguous and only
way to refer to "the current state of foo", but that was not how we
implemented the reflog, allowing a subtle repository corruption
where the latest state of a branch according to the reflog and the
current commit pointed by the branch can diverge. But that wasn't
what we did, and instead both "foo@{0}" and "foo" mean to refer to
"the latest state of foo". We can take advantage of that misdesign
and allow "foo@{0}" to refer to the same commit as "foo", at least
at the get_oid_basic() level, whether a reflog actually exists or
not, and that would make the whole thing more consistent.
In any case, I do not know how this "usability" actually helps in
the field, and I wouldn't personally shed tears if it gets removed.
The above is just an explanation why it exists.
Thanks.
