When tags and branches match many refs, Sourcebot truncates to 64 revisions using revisions.slice(0, 64) after listing tags via plain git.tags() / git tag ordering. That order is ref-name order, not recency. For many repos this is naturally oldest tags first. I am guessing this is the opposite of what many users want.
Git already supports explicit ordering (e.g. git tag --sort=-creatordate, --sort=-committerdate, --sort=-version:refname). This request is to apply an explicit sort before truncation. And ideally have that exposed in the config.
Relation to unlimited branches / tags
There is already ongoing work toward removing the 64 revision cap #461 and related PRs). That helps orgs that want a full ref index.
Even with unlimited or much higher limits, a lot of people will still want optionally capped index size and cost. A newest N tags/branches or newest by last commit date policy seems like the natural knob to pass in.
Might be worth adding that sort option and keeping a cap in that other branch.
Currently right now I get my oldest x tags while working on software that matches live code to its sourcebot index for that tag. Naturally I am missing all tags.
When tags and branches match many refs, Sourcebot truncates to 64 revisions using
revisions.slice(0, 64)after listing tags via plaingit.tags()/git tagordering. That order is ref-name order, not recency. For many repos this is naturally oldest tags first. I am guessing this is the opposite of what many users want.Git already supports explicit ordering (e.g.
git tag --sort=-creatordate,--sort=-committerdate,--sort=-version:refname). This request is to apply an explicit sort before truncation. And ideally have that exposed in the config.Relation to unlimited branches / tags
There is already ongoing work toward removing the 64 revision cap #461 and related PRs). That helps orgs that want a full ref index.
Even with unlimited or much higher limits, a lot of people will still want optionally capped index size and cost. A newest N tags/branches or newest by last commit date policy seems like the natural knob to pass in.
Might be worth adding that sort option and keeping a cap in that other branch.
Currently right now I get my oldest x tags while working on software that matches live code to its sourcebot index for that tag. Naturally I am missing all tags.