Jeff King <peff@xxxxxxxx> writes:
> Let me try to lay out my thinking. If you _do_ have a reflog and the
> request (whether time or count-based) goes too far back, read_ref_at()
> will give you the oldest entry and return "1". And then in
> get_oid_basic():
> ...
> - what we _could_ do (but this series does not), and what would be the
> true counterpart to the @{20.years.ago} case, is to allow @{9999}
> for a reflog with only 20 entries, returning the old value from 20
> (or the new value if it was a creation!?) and issuing a warning
> saying "well, it only went back 20, but here you go".
Ah, I wasn't drawing *that* similarity. My thinking was more like
- When you have two entries in reflog, ref@{0} will use and find
the latest entry whose value is the same as the ref itself.
- When you have one entry, @{0} will use and find the latest entry
whose value is the same as the ref itself.
- When you have zero entry, @{0} can do the same by taking
advantage of the fact that its value is supposed to be the same
as the ref itself anyway.
that happens near the youngest end of a reflog, contrasting with the
@{20.years.ago} that happens near the oldest end.
> I'm not so sure about that last one. It is pretty subjective, but
> somehow asking for timestamps feels more "fuzzy" to me, and Git
> returning a fuzzy answer is OK. Whereas asking for item 9999 in a list
> with 20 items and getting back an answer feels more absolutely wrong. I
> could be persuaded if there were a concrete use case, but I can't really
> think of one. It seems more likely to confuse and hinder a user than to
> help them.
I do not think anybody misses @{9999} not giving the oldest
available, simply because "oldest" is a concept that fits better
with time-based queries than count-based queries.
