Jeff King <peff@xxxxxxxx> writes:
> the reflog entry we found. Instead, let's put the special case into the
> caller that resolves @{n}, as it cares only about the oid.
Thanks. I am quite puzzled why we didn't do this obvious thing from
the start.
> There is one complication, though. When read_ref_at() hits a truncated
> reflog, it will return the "old" value of the oldest entry only if it is
> not the null oid. Otherwise, it actually returns the "new" value from
> that entry! This bit of fudging is due to d1a4489a56 (avoid null SHA1 in
> oldest reflog, 2008-07-08), where asking for "ref@{20.years.ago}" for a
> ref created recently will produce the initial value as a convenience
> (even though technically it did not exist 20 years ago).
>
> But this convenience is only useful for time-based cutoffs. For
> count-based cutoffs, get_oid_basic() has always simply complained about
> going too far back:
>
> $ git rev-parse HEAD@{20}
> fatal: log for 'HEAD' only has 16 entries
>
> and we should continue to do so, rather than returning a nonsense value
> (there's even a test in t1508 already which covers this). So let's have
> the d1a4489a56 code kick in only when doing timestamp-based cutoffs.
Makes perfect sense.
> Signed-off-by: Jeff King <peff@xxxxxxxx>
> ---
> object-name.c | 9 +++++++++
> refs.c | 2 +-
> t/t1508-at-combinations.sh | 2 +-
> 3 files changed, 11 insertions(+), 2 deletions(-)
