That is an interesting one because, technically, it isn't a Conventional Commit anymore but that only matters if this isn't a transient state.

Completely agree, it is just a transient state, but it is a common workflow.

For example, I might be working on a PR with a few logically distinct commits, and I realise that one of the earlier commits has an error. I will create a fixup! commit temporarily, and then before rebasing the PR, I'll perform a rebase to automatically remove these fixes.

While implementing this, it should be noted that the same logic should apply for squash! commits, though the latter have the additional complexity of allowing the commit message to be amended.

Depending on how deep you want to go with this implementation, the ideal scenario would be to have the option to allow/forbid fixup! and squash! commits on a per branch basis. Specifically, forbidding fixup! and squash! on main and other long-lived branches, and then allowing these commits on all other branches.

If this is something you would be happy to see added to committed, I would be happy to work on the feature.

I might not have much time in the next week or so, but I could start end of next week or so.

For example, I might be working on a PR with a few logically distinct commits, and I realise that one of the earlier commits has an error. I will create a fixup! commit temporarily, and then before rebasing the PR, I'll perform a rebase to automatically remove these fixes.

To clarify, are you pushing your fixups or only keeping them local?

I've been considering some way to distinguish between local runs and CI runs. For example, I regularly have a WIP commit but I'd want CI to fail if thats present.

#394 jumps the gun. I did not say we were good for going forward. I was looking for a better understanding of the overall workflow to better understand what should happen.

No worries!

I've been considering some way to distinguish between local runs and CI runs. For example, I regularly have a WIP commit but I'd want CI to fail if thats present.

Within a PR, such commits might very well exist; but they should not land in the long lived branch.

This could be either because multiple people are working on the same PR, and therefore performing a rebase would be too disruptive. Alternatively, I might intend to squash-and-rebase the PR anyway, in which case the commits in the PR are effectively irrelevant.

I'll leave you reopen this if/when you want this implemented. If you have no intentions of doing so, let me know and I'll create a fork for my use cases.

I'll leave you reopen this if/when you want this implemented. If you have no intentions of doing so, let me know and I'll create a fork for my use cases.

Just because its undecided, doesn't mean it should be closed. For me, closing is for its rejected outright. I do not generally explore rejected issues for re-evaluating opening them.