Bug Report

Separated into its own issue from #1125, comments from @JonZeolla

Description

In order to resolve #1125, I implemented your two step workflow documented in #1125 (comment). And unfortunately it seems with v9.20.0, the 2 step workflow does not commit the version_variables and version_toml changes unless I intentionally stage them myself.

Expected behavior

The version_variables and version_toml configured files are committed with the release commit while also allowing me to keep uv.lock updated in between the steps.

Actual behavior

The version files were not committed in the release commit while the uv.lock was. The version files remained in the working directory

Environment

• Operating System (w/ version):
• Python version:
• Semantic-release version: v9.20.0

Configuration

[tool.semantic_release]
major_on_zero = false
version_toml = [
    "pyproject.toml:project.version",
]
version_variables = [
    "src/example/__init__.py:__version__",
]
changelog_file = "CHANGELOG.md"
commit_parser = "angular"
commit_author = "Example <Example@example.com>"
commit_message = "chore(release): example {version}"
tag_format = "example=={version}"

[tool.semantic_release.branches.release]
match = "main"

[tool.semantic_release.publish]
dist_glob_patterns = ["path_relative_to_root/example/dist/*"]
upload_to_vcs_release = true

[tool.semantic_release.remote]
name = "origin"
type = "github"
ignore_token_for_push = false
insecure = false

Execution Log

Additional context

My guess is that it's this and this. Since we stage the changes before running the --commit, the new_content is the same as self.content (in the working tree), so it returns None.

Then, that doesn't add the file path to paths here, which means it is not added to files_with_new_version_written here:

And then finally, it isn't staged and commit here: