Re: [PATCH] name-rev: include taggerdate in considering the best name

[Junio C Hamano <gitster@pobox.com>]

Junio C Hamano <gitster@pobox.com> writes:

> Jeff King <peff@peff.net> writes:
>
>> That turned out to be quite simple (I wasn't sure originally if we'd
>> actually visit all of the tags, which is why I had conceived of this as
>> an initial pass; but of course it makes sense that we'd have to see all
>> of the tags in the existing code).
>> ...
>> We could _also_ tweak the merge-weight as Linus's patch did, just
>> because 10000 has more basis than 65535. But I think it really matters a
>> lot less at this point.
>
> I agree, but if we were to go this route of keeping track of "some"
> attribute of the tip the traversal started from, I wonder if it is
> better to keep the actual tag object, not just its tagger date as an
> unsigned long, in the new field.

Actually, I take it back.  The "object" approach would not give us
enough flexibility to go beyond "date".  A light-weight tag that
directly point at a commit object can still yield "date" (probably
"committerdate" to be compared with other dates, be it the committer
date from another commit or the tagger date from a real tag), but if
we later wanted to do a v:refname kind of comparison, we'd need to
keep the name of the ref (we cannot go back from the commit object
to the refname), so at that point, we would be talking about adding
yet another field anyway to hold the refname, in addition to the
field we would be adding at this step.  As we do not want to be
always doing "name to object to date" conversion in this codepath,
adding an "unsigned long" date field is the right thing to do here.
A more elaborate future can add refname (or refname and object) as
additional fields, but we can wait because even after that update
the codepath to do date comparison likely would want to have direct
access to the date field anyway.