Re: [PATCH 2/3] get_oid_basic(): special-case ref@{n} for oldest reflog entry
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Feb 26, 2024, 15:59 UTC
- Message-ID
- <xmqqjzmrgqs1.fsf@gitster.g>
- In-Reply-To
- <20240226100407.GB2685600@coredump.intra.peff.net>
Jeff King <peff@peff.net> 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.
Show 18 quoted lines
> 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.
Show 6 quoted lines
> Signed-off-by: Jeff King <peff@peff.net> > --- > object-name.c | 9 +++++++++ > refs.c | 2 +- > t/t1508-at-combinations.sh | 2 +- > 3 files changed, 11 insertions(+), 2 deletions(-)