This would be very useful for me, since I have to add a boilerplate commit that adds a bunch of scaffolding downstream for my work, and that doesn't need to be in the changelogs.

Yeah this came across our minds as well, but wanted to get the very basic functionality right. How about a rpmautospec: prefix so it's clearer what this is about?

I don't mind that much about the form, as long as it is understandable by casual readers. [skip changelog] is understandable. rpmautospec: requires knowledge about rpmautospec.

[skip changelog] or [no changelog] is fine, but please don't put in the commit summary (this wasn't clear from the description).

Sure, I'd put it in the commit body.

E.g.:

Convert tabs to spaces
[skip changelog]

Or:

Spec cleanup
 - remove unreachable %if branches
 - delete obsolete comment
 - sort BuildRequires alphabetically
[skip changelog]

Another use case is reverted commits (#235). In my case (tin), there was an update which didn't build (Release: 1). A workaround was applied (Release: 2) and the package built. The workaround was found to be wrong and was reverted (Release: 3, no build attempt). A correct work-around was applied (Release: 4) and package built. I would've liked to have Release: 3 instead of 4 on the final package.

FWIW, while I think "no changelog" makes sense, I do think that we should still increment the build number when pushing a commit, even one that makes no functional changes (such as updating the gating.yaml). While cosmetically it might be nice to skip things like "tried this, reverted it", I think it introduces more risk to the upgrade path than needed.

Yes, the build number should be increased. I think that it's a totally separate issue, and as you say, it'd be very risky to not do that.

Commit 066d4bea fixes this issue