## gbp-rpm-ch

gbp-rpm-ch; — Generate the RPM changelog from git commit messages

## Synopsis

`gbp rpm-ch` [`--version`] [`--help`] [`--verbose`] [`--color=`[auto|on|off]] [`--color-scheme=``COLOR_SCHEME`] [`--tmp-dir`=`DIRECTORY`] [`--vendor`=`VENDOR`] [`--packaging-branch=``BRANCH-NAME`] [`--packaging-tag=``TAG-FORMAT`] [`--ignore-branch`] [`--packaging-dir=``DIRECTORY`] [`--changelog-file=``FILEPATH`] [`--spec-file=``FILEPATH`] [`--since=``COMMITISH`] [`--no-release`] [`--[no-]git-author`] [`--[no-]full`] [`--id-length=``NUMBER`] [`--ignore-regex=``REGEX`] [`--changelog-revision=``REV-FORMAT`] [`--git-log=``GIT-LOG-OPTIONS`] [`--spawn-editor=`[always|release|no]``] [`--editor-cmd=``EDITOR`] [`--customizations=``CUSTOMIZATION-FILE`] `[PATH1 PATH2]`

## DESCRIPTION

gbp rpm-ch reads git commit messages up to the current tip of the current branch and updates the RPM changelog from them.

By default, gbp rpm-ch tries to guess the last Git™ commit documented in the changelog. Alternatively, `--since` can be used to tell gbp rpm-ch at which point it should start in the Git™ history, or, `--all` to use all commits from the Git™ history.

The additional path arguments can be used to restrict the repository paths gbp rpm-ch looks at. For even more detailed control, you can use `--git-log` to restrict the generated changelog entries further. E.g. by using `--git-log=``"--author=Foo Bar"`.

## OPTIONS

`--version` | Print version of the program, i.e. version of the git-buildpackage suite
`-v`, `--verbose` | Verbose execution
`-h`, `--help` | Print help and exit
`--color=`[auto|on|off] | Whether to use colored output.

`--color-scheme=``COLOR_SCHEME`

Colors to use in output (when color is enabled). The format for COLOR_SCHEME is '<debug>:<info>:<warning>:<error>'. Numerical values and color names are accepted, empty fields imply the default color. For example, `--git-color-scheme=``'cyan:34::'` would show debug messages in cyan, info messages in blue and other messages in default (i.e. warning and error messages in red).

`--git-tmp-dir`=`DIRECTORY` | Base directory under which temporary directories are created.
`--vendor`=`VENDOR` | Distribution vendor name.
`--packaging-branch`=`BRANCH-NAME` | The branch in the Git repository the package is being developed on, default is `master`.
`--ignore-branch` | Don't check if the current branch matches `PACKAGING-BRANCH`.
`--packaging-tag=``TAG-FORMAT` | Tag format used, when tagging releases, default is `%(vendor)s/%(version)s`
`--packaging-dir=``DIRECTORY` | Subdirectory that contains the RPM packaging files.
`--changelog-file=``FILEPATH` | Relative path to the changelog file to use. Special value `auto` causes gbp to guess, `SPEC` uses the spec file, `CHANGES` uses a separate changelog file (name derived spec file name with .spec suffix replaced by .changes). Guessing logic is simple: use separate changelog file if it is found, otherwise use the spec file.
`--spec-file=``FILEPATH` | Relative path to the spec file to use. Special value `auto` causes gbp to search and guess. Other values cause the `--packaging-dir` option to be ignored: the directory of the spec file is used, instead.
`--since=``COMMITTISH` | Start reading commit messages at `COMMITTISH`.
`--no-release` | Do not create a new changelog section, just update the last changelog section.
`--[no-]full` | Include the full commit message in the changelog output.
`--git-log=``GIT-LOG-OPTIONS` | Options passed on verbatim to git-log(1).
`--id-length=``N` | Include `N` digits of the commit id in the changelog entry. Default is to not include any commit ids at all.
`--ignore-regex=``REGEX` | Ignore lines in commit message matching `REGEX` when generating the changelog.

`--changelog-revision=``REV-FORMAT`

Format string to use for revision field in the changelog header. The following string fields are accepted: `%(upstreamversion)s` the upstream version; `%(release)s` the rpm patchlevel, i.e. Release; `%(version)s` full rpm package version; `%(tagname)s` tag/commit, i.e. basically what git-describe would give. If empty or not defined the default from packaging policy is used.

`--ignore-regex=``REGEX` | Ignore commit lines matching `REGEX` when generating the changelog.
`--[no-]git-author` | Use user.name and user.email from git-config(1) for the changelog header.
`--spawn-editor=`[always|release|no]`` | Whether to spawn an editor: always, when doing a release or never.
`--editor-cmd=`EDITOR`` | The editor to use for editing the changelog.
`--customizations=``CUSTOMIZATION-FILE` | Load Python code from `CUSTOMIZATION-FILE`. At the moment, the only useful thing the code can do is define a custom ChangelogEntryFormatter class.

## META TAGS

Additional to the above options the formatting of the new changelog entries (one-per-commit) in the changelog can be modified by special tags (called Meta Tags) given in the git commit message. The tags must start at the first column of a commit message but can appear on any line. They are of the form `Tagname`: `VALUE`. Valid Meta Tags are:

`Git-Rpm-Ch`: `ACTION` | Supported actions are: `Ignore` which will ignore this commit when generating new changelog entries. `Short` which will only use the description (the first line) of the commit message when generating the changelog entry (useful when `--full` is given) and `Full` which will use the full commit message when generating the changelog entry (useful when `--full` is not given).
`[Close|Closes|...]`: `BUGNUMBER` | Indicate in the changelog entry that bug `BUGNUMBER` was addressed in this commit.

The following git commit message:

          Document meta tags

          so one doesn't have to consult the manual

          Git-Rpm-Ch: Short
          Closes: #636088

Results in this changelog entry:

          - Document meta tags (Closes: #636088)

## CONFIGURATION FILES

Several `gbp.conf` files are parsed to set defaults for the above command-line arguments. See the gbp.conf(5) manpage for details.

## SEE ALSO

gbp-buildpackage-rpm(1), gbp-import-srpm(1), gbp.conf(5), debuild(1), git(1), pristine-tar(1), The Git-Buildpackage Manual Cl2vcs,

## AUTHOR

Markus Lehtonen `<markus.lehtonen@linux.intel.com>`