A utility (and eventual create) for working with conventional commits in Git repository.
Find a file
2024-03-11 09:56:43 -05:00
src fix: maybe check the message of the current commit instead 2024-03-10 18:04:03 -05:00
.editorconfig chore: initial commit of ideas 2024-03-09 01:00:57 -06:00
.envrc chore: initial commit of ideas 2024-03-09 01:00:57 -06:00
.gitignore chore: initial commit of ideas 2024-03-09 01:00:57 -06:00
.prettierignore chore: initial commit of ideas 2024-03-09 01:00:57 -06:00
Cargo.lock feat: added file matching to the commits 2024-03-09 22:02:47 -06:00
Cargo.toml feat: added file matching to the commits 2024-03-09 22:02:47 -06:00
CODE_OF_CONDUCT.md chore: initial commit of ideas 2024-03-09 01:00:57 -06:00
DCO.md chore: initial commit of ideas 2024-03-09 01:00:57 -06:00
flake.lock build: packaged for a flake 2024-03-09 22:51:46 -06:00
flake.nix build: packaged for a flake 2024-03-09 22:51:46 -06:00
README.md docs: tweaking read me 2024-03-11 09:56:43 -05:00
rust-toolchain.toml chore: initial commit of ideas 2024-03-09 01:00:57 -06:00

MfGames Conventional Commit

A small utility that calculates the sematic version from conventional commits in a Git repository.

This utility does one thing only, calculate the semantic version from Git commits that conform to the conventional commit specification. It is path-aware which means only commits inside certain directories are included in the calculation. The current version number is built from the highest sematic version tag found in the commit's parents.

For example, the version of "Package1" will be 1.2.4 and "Package2" will be 1.3.0 from the following commits:

  • fix: fixing package1
    • src/package1/file1.txt
  • feat: fixing package2
    • src/package2/file2.txt
  • fix: sweeping change
    • src/package1/file.txt
    • src/package2/file.txt
  • feat: current version [tagged "Package1-1.2.3", "Package2-1.2.3"]
    • src/package1/file.txt
    • src/package2/file.txt

In the above example, the second commit is ignored while calculating the "Package1" commits while the first one is ignored while calculating "Package2".

If a version cannot be found, this will use 0.0.1.

Configuration

Configuration is done via a file checked into the Git root in .config/mfgames-conventional-commit.json. An example file is below:

{
  "$schema": "https://mfgames.com/mfgames-conventional-commit/schemas/v0.0.json",
  "packages": {
    "Package1": {
      "tag_prefix": "Package1-*",
      "paths": { "include": ["src/package1/**/*"] }
    },
    "Package2": {
      "tag_prefix": "Package2-*",
      "paths": { "include": ["src/package2/**/*"] }
    }
  }
}

To use this in a single package repository, the following can be used:

{
  "$schema": "https://mfgames.com/mfgames-conventional-commit/schemas/v0.0.json",
  "packages": {
    "default": {
      "tag_prefix": "v*",
      "paths": { "include": ["**/*"] }
    }
  }
}

At the moment, configuration has poor error handling, so if the program says it cannot read the configuration file, check the file. The schema will change "soon".

Usage

The executable is mfgames-conventional-commit.

mfgames-conventional-commit --package Package1

Options

--directory PATH

The directory (or sub-directory) inside the Git repository. If this is not provided, then the current working directory will be used.

--package NAME

Required

The name of the package, case-sensitive, that matches the package name inside the configuration. This can be used anywhere within the Git repository, not just within the directories for that project.

In the future, this will not be required if run inside a directory that only exists inside a single project.

-v, --verbose

Increase the level of verbosity. At default, this will only show warnings and errors on stderr and write out the calculated version on stdout. When this option is given (three levels), it will write out increasingly more information about how the version is calculated.