diff --git a/sunrise-commit.1.in b/sunrise-commit.1.in
index f9c4e58..4ed6498 100644
--- a/sunrise-commit.1.in
+++ b/sunrise-commit.1.in
@@ -103,47 +103,54 @@ The sunrise-suggested format is:
 
 .SH "EXTENDED DESCRIPTION"
 
-.IP "Adding packages"
+.IP "Adding and Updating Packages"
 
-The primary use of sunrise-commit is to commit packages to a repository.
-In order to use it in this scenario, you are expected to run it from
-within the package directory (one with the ebuilds), providing
-an appropriate changelog message.
+The primary use of \fBsunrise-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) you need to commit it
-manually \fBbefore\fP using sunrise-commit.
+the package directory (e.g. an eclass, a license), then you need to
+commit that file manually \fBbefore\fP using \fBsunrise-commit\fP.
 
-What sunrise-commit will do for you is the ChangeLog entry and calling
-repoman to do the actual commit. If you think your commit doesn't
-deserve a ChangeLog entry, use \fB--trivial\fP.
+\fBsunrise-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're adding a new package, it may be also necessary to use
-\fB--noupdate\fP to avoid calling VCS update command as it could fail
-with a freshly created directory (especially with subversion).
+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 \fBsunrise-commit\fP from calling the
+VCS's update command (which only happens if you are not using DVCS).
 
-.IP "Removing packages"
+.IP "Removing Packages"
 
-sunrise-commit can be used to remove a set of packages too. In order to
-do so, first mark all the expected packages removed using your VCS.
-Perform the necessary \fBpackage.mask\fP changes too, and remove
+\fBsunrise-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 \fBsunrise-commit\fP from within your repository root
-directory, passing the removal reason. The script will prepend it with
-the complete removed package list.
+Afterwards, call \fBsunrise-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 notice that it will commit all changes in \fBeclass\fP,
-\fBlicenses\fP and \fBprofiles\fP directories too. This is in order to
-accomodate the need of removing \fBpackage.mask\fP entries and unused
-files but could cause trouble if the working copy is dirty.
+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.
 
-sunrise-commit will check whether the removed package is not referenced
-by any of the other packages by default. 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 want to pass \fB--force\fP in order to ignore that
-check.
+\fBsunrise-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.
 
 .SH EXAMPLES
 
@@ -177,7 +184,7 @@ $ cd app-foo/bar
 $ sunrise-commit -t 'Fixing a broken Manifest.'
 .fi
 
-(\fB sunrise-commit\fP always updates the Manifest)
+(\fBsunrise-commit\fP always updates the Manifest)
 
 .I "4. Removing a package which was added to gx86:"