FinderGit 0.33.0

Git has two kinds of tag. The Release tab has always shown both and never said which was which — this release is that difference, made visible.

A tag that sat at the bottom, and was not a sorting bug

On a repository here, v1.0.2 sat at the very bottom of two hundred rows, below v1.0.1. Nothing was wrong with the sort.

An annotated tag is an object with a creation date. A lightweight tag is only a name: Git records nothing about when it was made, because there is no such field. So the date shown for it is the commit's — and v1.0.2 names a commit six days older than the v1.0.1 tag object. The list was correct and read as though it were broken, and there was no order in which it read right.

The header now carries a Date / Version picker. Version order reads the names, which also fixes what alphabetical gets backwards: v26.10 belongs above v26.2, and a release belongs above its own release candidates — v24.6.3 over v24.6.3-rc.0, not under it. Date stays the default; nothing moves unless you ask.

Every tag row says something now

A lightweight tag carries no message, so half the rows had nothing under the name and the gap read as a rendering fault. They now show the subject of the commit the tag points at.

Never styled as a tag message, though — behind a small commit mark, in a lighter grey. The two are sentences written by different people at different times, and a commit subject printed under the heading "tag message" is a caption that lies. The row labels which one you are reading rather than quietly filling the gap.

The date says what it measures

Hover it and it tells you: when the tag was made, or when the commit was. That is the sentence that explains a tag sitting somewhere surprising, and it is why the picker above is a choice rather than a silent change of behaviour.

Open the tag, not just the release

A release could always be opened in a browser. A tag could not — and the tag is the half that exists in every repository, since releases are a forge feature and a tag is just Git.

Each row now carries the same arrow the release side has, and the menu gains Open Tag on GitHub (or GitLab, Codeberg, Bitbucket) and Copy Tag Link. They appear only where the forge can be expected to have that page: on a tag marked local only — a measured answer, origin was asked and did not have it — they are not drawn, because a link into a 404 is worse than no link.

Fixes

• The filter now searches what the row shows. A tag could display Merge john_resource-labels-fix into staging and return nothing when you typed any word of it. It now matches the row's second line, whichever of the two sentences that is — and only that, so it never returns rows with no visible reason to be there.

Under the hood

Version ordering is a real comparison, not a spelling one: the pre-release rule is where a plain natural-order compare fails, since v24.6.3-rc.0 is the longer string and sorts above the release it was a candidate for. Non-version names are kept together at the end rather than read as 0.0.0.

It also had to be cheap. Comparing two names parses both, and a sort makes n·log n of those — measured at 13.5 ms over 700 tags, against a 16.7 ms frame, on a list that is rebuilt on every click. Parsing once per name instead brings it to 0.39 ms, the same order as sorting by date.

The commit subject needed a new field rather than a fallback, because it arrives from a different for-each-ref field for each kind of tag, and reading one field for both is how an annotated tag ends up printing its own message twice — once labelled as the commit's.

Verify this download

Compare the checksum of the file you downloaded:

shasum -a 256 FinderGit-0.33.0.dmg

It must print exactly:

a31e02094ab3511df39dd71a6826760995c7c4a3b244e7e061096d66fcb40b0e

The DMG is also signed with an Apple Developer ID and notarized by Apple, which you can confirm without installing it:

spctl -a -vv -t open --context context:primary-signature FinderGit-0.33.0.dmg

That reports source=Notarized Developer ID for a genuine build.