๐๏ธ FinderGit 0.32.0 โ delete a tag everywhere, and the order it does it in
๐๏ธ FinderGit 0.32.0 is out, and this one came entirely from using the thing on real data.
0.31.0 let you select many tags and act on them at once. Worked great โ until someone opened it on a repo with 715 tags, scrolled down to the release candidates from four years ago, selected three, and found that the bar with every action for that selection was several hundred rows above, off the top of the panel ๐
You could build a ten-tag selection and have no way to see what you could do with it.
๐ The header and the selection bar are pinned now. The list scrolls underneath them. Wherever you build a selection, its actions are on screen.

๐ฑ๏ธ Right-click works on both halves of a row, and they're different menus on purpose โ a tag and a release are two different objects with an optional link between them.
on a tag: fetch, push, delete, copy its name, copy the commit it points at
on a release: open in browser, copy its link, copy the tag it came from
Right-click a tag inside a selection and the menu is about the selection, each item saying how many tags it acts on. And that's the number it applies to, not how many rows are lit: Push over five tags of which two are already on origin acts on three, and says three.
๐ฅ And the one people asked for: delete a tag everywhere, in one action.
Here's the part I want to talk about though โ it runs the remote first, and that's not an implementation detail, it's the whole safety argument ๐
If the remote deletion fails (protected tag, permission denied), your local tag is untouched. Nothing is lost, the run stops there for that tag, you retry. The other order destroys the last reference naming that commit and then discovers it can't reach origin.
When a run does stop half way it tells you which side it stopped on. Sounds pedantic; it isn't. A tag still on origin needs the whole thing again. One already gone from origin only needs deleting locally. "Three of ten failed" can't tell those apart, and a blind retry on the second kind does the wrong thing.
โ ๏ธ The confirmation also spells out the bit almost nobody expects, which we measured rather than assumed: on GitHub, deleting a tag doesn't delete its release. It turns it into a draft, which vanishes from the public releases page โ and pushing the tag back does NOT bring it back.
๐งน The three deletions now sit behind one Delete menu instead of three buttons in a row. Destructive things should cost a deliberate second gesture.
๐ Plus a fix I'm mildly embarrassed by: selecting one tag read "1 tag selezionati" in Italian, and the equivalent in French, German and Spanish. The phrase inflects itself in English and not in the translations, so every count got the plural. Fixed, with a test that renders each language at one and at five and compares.
Free ยท universal binary ยท macOS 15+ ยท signed and notarized.
๐ Try it / see what's new: https://findergit.app
Curious about one thing: when you delete a tag for good, do you do remote-then-local by habit, or had you never thought about the order until it bit you? ๐


Replies
"The remote-first order makes total sense โ and honestly, I'd never thought about it until reading this. My instinct was always to delete locally first because it felt 'safer,' but your point about destroying the last reference before confirming the remote is reachable changes how I think about it.
The GitHub release-to-draft behaviour is the part that really surprised me. I had no idea pushing the tag back doesn't restore the release. That's the kind of detail that only shows up when you actually measure it.
Nice to see you shipping again after octoscope โ same level of care in the details. ๐"