Add option to omit (or automatically reuse) Release xxx commits?

[MarijnS95]

As I'm still experimenting with a custom registry and publishing our workspace with various "interesting" build scripts and dependencies, publishing fails from time to time. This means smart-release has created a massive Release xxx commit with all crate names, tagged a few crates there, and then terminates until I fix the error manually.

Subsequently running smart-release after addressing the issues will create a new commit with again a lot of crate names. Would it be possible to not create this commit (maybe even automatically if the title/contents match what we're about to release) so that eventually all tags and .cargo_vcs_info.json point to the same release commit?

(I know that this is not applicable when code changes are required within my git repository - to be committed separately - but would help with spurious failures on my registry or patch bumps of related dependency crates)

[Byron]

The way I'd improve the situation is to give it a way to roll-back this particular change unless such auto-rollback is disabled explicitly. That way, one wouldn't be left with what seems like a commit and a bunch of tags.

The reason it is the way it is is simply that it can deal with this, and that it's nice to manually examine the intermediate step with all the manifest changes. Once or twice I was able to recover from an otherwise permanent failure by 'helping' the manifests along.

Actually doing so has been rare though and I can see that by default it should rather clean up after itself if no crate was published or no other networked interaction was performed and succeeded.

I have turned this into an Idea to be fleshed out to see if what I am proposing here would even suit your needs. Reusing this commit I find unfeasible as it would require understanding it, and omitting it isn't possible as the manifest changes have to go somewhere to before being taggable.

[MarijnS95]

A rollback would imply magically yanking all crates that did succeed. I'm merely talking about the case where no changes need to be made to the crates, the process just failed halfway through (network trouble, spurious registry outage, ...). Here it could piggy-back off the last commit and just tag whatever HEAD is still pointing to instead of creating a new commit.

[Byron]

Yes, that seems reasonable! A good hint could be if the commit would be empty and no manifest change is actually done, then it could fall back to the previous commit if it is its own, and possibly to any commit as it includes the desired state.