.TH SUNRISE-COMMIT 1 "13 Jul 2010" "@PACKAGE_STRING@" "User Commands"
repo-commit \- a Gentoo repository commit helper.
is a helper script for Gentoo repository commiters. Apart from
performing the actual commit, it performs the following tasks:
\- performs basic integrity and QA checks on the modified packages,
\- handles ChangeLog and Manifest updates,
\- prepends the commit message with package name(s).
The script supports CVS, GIT, Mercurial, and Subversion repositories.
For the latter, it supports native checkouts as well as git-svn.
Please note that when used with DVCSes, this script only performs the
actual commit. (It does not push or dcommit it to the repository).
However, native Subversion and CVS commits are sent directly to the remote
repository (due to limitations of non-distributed VCSes).
.IP "\fB-c\fP, \fB--changelog\fP"
Force creating a ChangeLog even if DVCS is used. Otherwise, ChangeLog
entries will be created if needed. Use \fB--trivial\fP to suppress
creation of ChangeLog entries.
Because of the nature of DVCSes, a ChangeLog will not be created for a
new ebuild in a GIT or Mercurial repository. However, if the ebuild
already has a ChangeLog file, it will be updated. One consideration is
that if a ChangeLog file is maintained and the repository needs to be
merged after two people adjust the same ebuild, the ChangeLog will
cause merge conflicts. Also, viewing a DVCS's log does not require an
.IP "\fB-C\fP, \fB--nocolor\fP"
Disable colorful output (for terminals which do not support escape
.IP "\fB-d\fP, \fB--noupdate\fP"
Do not update and rebase the repository before proceeding with the
commit. This option only applies to Subversion and CVS repositories.
It makes no sense to automatically pull from remote DVCS repositories.
.IP "\fB-f\fP, \fB--force\fP"
Force proceeding with the commit even if QA violations occur. With
this option, errors from `\fIrepoman full\fP' will be ignored and
\fB--force\fP is passed to `\fIrepoman commit\fP'.
.IP "\fB-H\fP, \fB--nochangelog\fP"
Disable appending ChangeLog entries and reverting them. In other words,
this option makes sure \fBrepo-commit\fP won't touch the ChangeLog at
.IP "\fB-m\fP, \fB--noformat\fP"
Do not prepend the commit message with package names.
.IP "\fB-q\fP, \fB--quiet\fP"
Ignored (provided for backwards compatibility).
.IP "\fB-t\fP, \fB--trivial\fP"
Assume the changes are trivial and thus do not require a ChangeLog
entry. Examples of trivial changes include updating Manifests and
minor correction of previous ChangeLog entries.
.IP "\fB-v\fP, \fB--verbose\fP"
Enable verbose output. Useful mostly for debugging.
.IP "\fB-?\fP, \fB-h\fP, \fB--help\fP"
Print a short help message and exit.
.IP "\fB-V\fP, \fB--version\fP"
Print the version string and exit.
The committer name and e-mail as it would appear in ChangeLog.
The sunrise-suggested format is:
.IR "Real Name" " (" nickname ") <" e-mail >
`\fInickname\fP' corresponds to the committer's IRC nickname.
.SH "EXTENDED DESCRIPTION"
.IP "Adding and Updating Packages"
The primary use of \fBrepo-commit\fP is to add packages to a Gentoo
repository or update existing packages. In order to use it this way,
you are expected to run it from within the package's directory,
providing an appropriate changelog message. (The package's directory
is the directory holding its ebuilds).
If your package requires an additional file to be committed outside
the package directory (e.g. an eclass, a license), then you need to
commit that file manually \fBbefore\fP using \fBrepo-commit\fP.
\fBrepo-commit\fP will update the ChangeLog entry and call
.BR repoman (1)
to do the actual commit for you. If the package's ChangeLog should
\fBnot\fP be updated for a particular commit, use \fB--trivial\fP.
If you are adding a new package and using subversion or a similar VCS,
you may get a warning that your VCS's update command failed. For
example, subversion's update command fails when run from a newly added,
but not yet committed, directory. To avoid this warning, you may use
\fB--noupdate\fP. This option prevents \fBrepo-commit\fP from calling the
VCS's update command (which only happens if you are not using DVCS).
.IP "Removing Packages"
\fBrepo-commit\fP can be used to remove a set of packages too. In order to
do so, first mark all the expected packages as removed using your VCS.
Next, perform the necessary \fBpackage.mask\fP changes and remove
licenses no longer in use.
Afterwards, call \fBrepo-commit\fP from within your repository's root
directory, passing the removal reason as an argument. The script will
prepend your commit message with the complete removed package list.
Please note that all changes in the \fBeclass\fP, \fBlicenses\fP, and
\fBprofiles\fP directories will be committed too. This accomodates an
atomic package removal commit, where \fBpackage.mask\fP entries and
files used only by the removed packages are removed. However, this can
cause trouble if the working copy is dirty.
\fBrepo-commit\fP will check whether any removed package is still
referenced by any of the other packages by default. If it finds an
internal package reference, it will give an error message. This is in
order to ensure that no package will be left with unsatisfied
dependencies. However, if you're removing the package because it was
moved to a master repository (e.g. gx86), you may use \fB--force\fP to
ignore that check.
All of the following examples assume that the committer is using a
native Subversion repository and that the initial working directory is
the branch's or repository's root.
.I "1. Adding a new ebuild:"
$ svn mkdir app-foo/bar
$ cd app-foo/bar
$ svn add bar-1.ebuild
$ repo-commit 'New ebuild for bug #nnnnnn.'
.I "2. Performing a version bump:"
$ cd app-foo/bar
$ svn mv bar-1.ebuild bar-2.ebuild
$ repo-commit 'Version bump.'
.I "3. Fixing a broken Manifest:"
$ cd app-foo/bar
$ repo-commit -t 'Fixing a broken Manifest.'
(\fBrepo-commit\fP always updates the Manifest)
.I "4. Removing a package which was added to gx86:"
$ svn rm app-foo/bar
$ repo-commit -f 'in gx86.'
.SH "REPORTING BUGS"
Please report bugs via Gentoo Bugzilla:
Michal Gorny <firstname.lastname@example.org>
Nathan Phillip Brink <email@example.com>
.SH "SEE ALSO"
.BR ebuild (5),
.BR echangelog (1),
.BR cvs (1),
.BR git (1),
.BR hg (1),
.BR repoman (1),
.BR svn (1)