wip links still broken

Author: bearomorphism

docs/commands/bump.md

@@ -30,7 +30,7 @@ The version follows the `MAJOR.MINOR.PATCH` format, with increments determined b
 | `MINOR`   | New features                | `feat`                  |
 | `PATCH`   | Fixes and improvements      | `fix`, `perf`, `refactor`|
 
-### Version Schemes (`--version-scheme`)
+### `--version-scheme`
 
 By default, Commitizen uses [PEP 440][pep440] for version formatting. You can switch to semantic versioning using either:
 
@@ -260,6 +260,9 @@ For example, in `pyproject.toml`:
 annotated_tag = true
 ```
 
+!!! note
+    By default, Commitizen uses lightweight tags.
+
 ### `--annotated-tag-message`
 
 Create annotated tags with the given message.
@@ -351,6 +354,9 @@ Creates gpg signed tags.
 cz bump --gpg-sign
 ```
 
+!!! note
+    By default, Commitizen uses lightweight tags.
+
 ### `--template`
 
 Provides your own changelog jinja template.
@@ -455,9 +461,7 @@ Allow the project version to be bumped even when there's no eligible version.
 
 See [Version Schemes](#version-schemes-version-scheme).
 
-## Configuration file options
-
-### `tag_format`
+### `--tag-format`
 
 `tag_format` and [`version_scheme`](#version-schemes-version-scheme) are combined to make Git tag names from versions.
 
@@ -501,199 +505,8 @@ Supported variables:
 | `$prerelease`, `${prerelease}` | Prerelease (alpha, beta, release candidate) |
 | `$devrelease`, `${devrelease}` | Development release                         |
 
-### `version_files`
-
-Identify the files or glob patterns which should be updated with the new version.
-
-Commitizen will update its configuration file automatically when bumping,
-regardless of whether the file is present or not in `version_files`.
-
-You may specify the `version_files` in your configuration file.
-
-```toml title="pyproject.toml"
-[tool.commitizen]
-version_files = [
-    "src/__version__.py",
-]
-```
-
-It is also possible to provide a pattern for each file, separated by a colon (e.g. `file:pattern`). See the below example for more details.
-
-```toml title="pyproject.toml"
-[tool.commitizen]
-version_files = [
-    "packages/*/pyproject.toml:version",
-    "setup.json:version",
-]
-```
-
-#### Example scenario
-
-We have a project with the following configuration file `pyproject.toml`:
-
-```toml title="pyproject.toml"
-[tool.commitizen]
-version_files = [
-    "src/__version__.py",
-    "packages/*/pyproject.toml:version",
-    "setup.json:version",
-]
-```
-
-For the reference `"setup.json:version"`, it means that it will look for a file `setup.json` and will only change the lines that contain the substring `"version"`.
-
-For example, if the content of `setup.json` is:
-
-<!-- DEPENDENCY: repeated_version_number.json -->
-
-```json title="setup.json"
-{
-  "name": "magictool",
-  "version": "1.2.3",
-  "dependencies": {
-      "lodash": "1.2.3"
-  }
-}
-```
-
-After running `cz bump 2.0.0`, its content will be updated to:
-
-```diff title="setup.json"
-{
-  "name": "magictool",
-- "version": "1.2.3",
-+ "version": "2.0.0",
-  "dependencies": {
-      "lodash": "1.2.3"
-  }
-}
-```
-
-!!! note
-    Files can be specified using relative (to the execution) paths, absolute paths, or glob patterns.
-
-!!! note "Historical note"
-    This option was renamed from `files` to `version_files`.
-
-### `bump_message`
-
-Template used to specify the commit message generated when bumping.
-
-Defaults to: `bump: version $current_version → $new_version`
-
-| Variable           | Description                         |
-| ------------------ | ----------------------------------- |
-| `$current_version` | the version existing before bumping |
-| `$new_version`     | version generated after bumping     |
-
-#### Example configuration
-
-```toml title="pyproject.toml"
-[tool.commitizen]
-bump_message = "release $current_version → $new_version [skip-ci]"
-```
-
-### `update_changelog_on_bump`
 
-When set to `true`, `cz bump` is equivalent to `cz bump --changelog`.
-
-```toml title="pyproject.toml"
-[tool.commitizen]
-update_changelog_on_bump = true
-```
-
-### `annotated_tag`
-
-When set to `true`, `cz bump` is equivalent to `cz bump --annotated-tag`.
-
-```toml title="pyproject.toml"
-[tool.commitizen]
-annotated_tag = true
-```
-
-### `gpg_sign`
-
-When set to `true`, `cz bump` is equivalent to `cz bump --gpg-sign`. See [--gpg-sign](#-gpg-sign).
-
-```toml title="pyproject.toml"
-[tool.commitizen]
-gpg_sign = true
-```
-
-### `major_version_zero`
-
-When set to `true`, `cz bump` is equivalent to `cz bump --major-version-zero`. See [--major-version-zero](#-major-version-zero).
-
-```toml title="pyproject.toml"
-[tool.commitizen]
-major_version_zero = true
-```
-
-### `pre_bump_hooks`
-
-A list of optional commands that will run right _after_ updating [`version_files`](#version_files)
-and _before_ actual committing and tagging the release.
-
-Useful when you need to generate documentation based on the new version. During
-execution of the script, some environment variables are available:
-
-| Variable                     | Description                                                |
-| ---------------------------- | ---------------------------------------------------------- |
-| `CZ_PRE_IS_INITIAL`          | `True` when this is the initial release, `False` otherwise |
-| `CZ_PRE_CURRENT_VERSION`     | Current version, before the bump                           |
-| `CZ_PRE_CURRENT_TAG_VERSION` | Current version tag, before the bump                       |
-| `CZ_PRE_NEW_VERSION`         | New version, after the bump                                |
-| `CZ_PRE_NEW_TAG_VERSION`     | New version tag, after the bump                            |
-| `CZ_PRE_MESSAGE`             | Commit message of the bump                                 |
-| `CZ_PRE_INCREMENT`           | Whether this is a `MAJOR`, `MINOR` or `PATCH` release       |
-| `CZ_PRE_CHANGELOG_FILE_NAME` | Path to the changelog file, if available                   |
-
-```toml title="pyproject.toml"
-[tool.commitizen]
-pre_bump_hooks = [
-  "scripts/generate_documentation.sh"
-]
-```
-
-### `post_bump_hooks`
-
-A list of optional commands that will run right _after_ committing and tagging the release.
-
-Useful when you need to send notifications about a release, or further automate deploying the
-release. During execution of the script, some environment variables are available:
-
-| Variable                       | Description                                                 |
-| ------------------------------ | ----------------------------------------------------------- |
-| `CZ_POST_WAS_INITIAL`          | `True` when this was the initial release, `False` otherwise |
-| `CZ_POST_PREVIOUS_VERSION`     | Previous version, before the bump                           |
-| `CZ_POST_PREVIOUS_TAG_VERSION` | Previous version tag, before the bump                       |
-| `CZ_POST_CURRENT_VERSION`      | Current version, after the bump                             |
-| `CZ_POST_CURRENT_TAG_VERSION`  | Current version tag, after the bump                         |
-| `CZ_POST_MESSAGE`              | Commit message of the bump                                  |
-| `CZ_POST_INCREMENT`            | Whether this was a `MAJOR`, `MINOR` or `PATCH` release      |
-| `CZ_POST_CHANGELOG_FILE_NAME`  | Path to the changelog file, if available                    |
-
-```toml title="pyproject.toml"
-[tool.commitizen]
-post_bump_hooks = [
-  "scripts/slack_notification.sh"
-]
-```
-
-### `prerelease_offset`
-
-Offset with which to start counting prereleases.
-
-Defaults to: `0`
-
-```toml title="pyproject.toml"
-[tool.commitizen]
-prerelease_offset = 1
-```
-
-### `version_scheme`
-
-See [Version Schemes](#version-schemes-version-scheme).
+## Configuration file options
 
 ## Avoid raising errors