+@example
+git log -10 --oneline
+@end example
+
+If you're using an older version of Git and get an @q{unrecognized
+argument} error, use this instead:
+
+@example
+git log -10 --pretty=oneline --abbrev-commit
+@end example
+
+More interactive lists of the commits on the remote @code{master}
+branch are available at
+@uref{http://git.sv.gnu.org/gitweb/?p=lilypond.git;a=shortlog} and
+@uref{http://git.sv.gnu.org/cgit/lilypond.git/log/}.
+
+
+@node How to make a commit
+@unnumberedsubsubsec How to make a commit
+
+
+Once you have modified some source files in your working
+directory, you can make a commit with the following procedure:
+
+@enumerate
+@item
+Make sure you've configured Git properly (see @ref{Configuring
+Git}). Check that your changes meet the requirements described in
+@ref{Code style} and/or @ref{Documentation policy}. For advanced
+edits, you may also want to verify that the changes don't break
+the compilation process.
+
+@item
+Run the following command:
+
+@example
+git status
+@end example
+
+@noindent
+to make sure you're on the right branch, and to see which files
+have been modified, added or removed, etc. You may need to tell
+Git about any files you've added by running one of these:
+
+@example
+git add @var{file} # add untracked @var{file} individually
+git add . # add all untracked files in current directory
+@end example
+
+@noindent
+After @command{git@tie{}add}, run @command{git@tie{}status} again
+to make sure you got everything. You may also need to modify
+@file{GNUmakefile}.
+
+@item
+Preview the changes about to be committed (to make sure everything
+looks right) with:
+
+@example
+git diff HEAD
+@end example
+
+@noindent
+The @code{HEAD} argument refers to the most recent commit on the
+currently checked-out branch.
+
+@item
+Generate the commit with:
+
+@example
+git commit -a
+@end example
+
+@noindent
+The @option{-a} is short for @option{--all} which includes modified
+and deleted files, but only those newly created files that have
+previously been added.
+
+@end enumerate
+
+
+@node Commit messages
+@unnumberedsubsubsec Commit messages
+
+
+When you run the @command{git@tie{}commit@tie{}-a} command, Git
+automatically opens the default text editor so you can enter a
+@emph{commit message}. If you find yourself in a foreign editing
+environment, you're probably in @command{vi} or @command{vim}. If
+you want to switch to an editor you're more familiar with, quit by
+typing @code{:q!} and pressing @code{<Enter>}. See
+@ref{Configuring Git} for instructions on changing the default
+editor.
+
+In any case, Git will open a text file for your commit message
+that looks like this:
+
+@example
+
+# Please enter the commit message for your changes. Lines starting
+# with '#' will be ignored, and an empty message aborts the commit.
+# On branch master
+# Changes to be committed:
+# (use "git reset HEAD <file>..." to unstage)
+#
+# modified: working.itexi
+#
+@end example
+
+Your commit message should begin with a one-line summary
+describing the change (no more than 50 characters long), and if
+necessary a blank line followed by several lines giving the
+details:
+
+@c $ git log -1 --pretty=medium 4d6f1e5
+@example
+Doc: add Baerenreiter and Henle solo cello suites
+
+Added comparison of solo cello suite engravings to new essay with
+high-res images, fixed cropping on Finale example.
+@end example
+
+Commit messages often start with a short prefix describing the
+general location of the changes.
+
+@itemize
+@item
+Doc: and Doc-@var{**}: If a commit affects the
+documentation in English (or in several languages simultaneously)
+the commit message should be prefixed with @qq{Doc:@tie{}}. If the
+commit affects only one of the translations, the commit
+message should be prefixed with @qq{Doc-@var{**}:@tie{}}, where
+@var{**} is the two-letter language code.
+
+@item
+Web: and Web-@var{**}: Commits that affect the
+website should use @qq{Web:@tie{}} for English, and
+@qq{Web-@var{**}:@tie{}} for other languages.
+
+@item
+CSS: Commits that change CSS files should use @qq{Web:@tie{}CSS:@tie{}}
+or @qq{Doc:@tie{}CSS:@tie{}} depending on whether they affect the
+website or the documentation/manuals.
+
+@item
+Changes to a single file are often prefixed with the name of the file
+involved.
+@end itemize
+
+Visit the links listed in @ref{Understanding commits} for examples.
+
+
+
+@node Patches
+@subsection Patches
+
+@menu
+* How to make a patch::
+* Emailing patches::
+@end menu
+
+@node How to make a patch
+@unnumberedsubsubsec How to make a patch
+
+If you want to share your changes with other contributors and
+developers, you need to generate @emph{patches} from your commits.
+We prefer it if you follow the instructions in
+@ref{Uploading a patch for review}. However, we present an
+alternate method here.
+
+You should always run @command{git@tie{}pull@tie{}-r} (translators
+should leave off the @option{-r}) before doing this to ensure that
+your patches are as current as possible.
+
+Once you have made one or more commits in your local repository,
+and pulled the most recent commits from the remote branch, you can
+generate patches from your local commits with the command:
+
+@example
+git format-patch origin
+@end example
+
+The @code{origin} argument refers to the remote tracking branch at
+@code{git.sv.gnu.org}. This command generates a separate patch
+for each commit that's in the current branch but not in the remote
+branch. Patches are placed in the current working directory and
+will have names that look something like this:
+
+@example
+0001-Doc-Fix-typos.patch
+0002-Web-Remove-dead-links.patch
+â‹®
+@end example
+
+Send an email (must be less than 64 KB) to
+@email{lilypond-devel@@gnu.org} briefly explaining your work, with
+the patch files attached. Translators should send patches to
+@email{translations@@lilynet.net}. After your patches are
+reviewed, the developers may push one or more of them to the main
+repository or discuss them with you.
+
+
+@node Emailing patches
+@unnumberedsubsubsec Emailing patches
+
+The default @code{x-diff} MIME type associated with patch files
+(i.e., files whose name ends in @code{.patch}) means that the
+encoding of line endings may be changed from UNIX to DOS format
+when they are sent as attachments. Attempting to apply such an
+inadvertently altered patch will cause git to fail with a message
+about @q{whitespace errors}.
+
+The solution to such problems is surprisingly simple---just change
+the default file extension of patches generated by git to end in
+@code{.txt}, for example:
+
+@example
+git config format.suffix '.patch.txt'
+@end example
+
+This should cause email programs to apply the correct base64
+encoding to attached patches.
+
+If you receive a patch with DOS instead of UNIX line-endings, it
+can be converted back using the @code{dos2unix} utility.
+
+Lots of useful information on email complications with patches is
+provided on the Wine wiki at
+@uref{http://wiki.winehq.org/GitWine}.
+
+
+@node Uploading a patch for review
+@subsection Uploading a patch for review
+
+Any non-trivial change should be uploaded to our @qq{Rietveld}
+code review website:
+
+@example
+@uref{http://codereview.appspot.com/}
+@end example
+
+You can upload a patch for review by using our custom @code{git-cl}
+@q{helper-script}. This section assumes you have already installed,
+updated, and configured @code{git-cl}. See @ref{git-cl}.
+
+@warning{Unless you are familiar with branches, only work on one
+set of changes at once.}
+
+There are two methods, depending on your git setup.
+
+@itemize
+@item
+@strong{Master branch}: (easy option)
+
+If you added your patch to @code{master}, then:
+
+@example
+git pull -r
+git-cl upload origin/master
+@end example
+
+@c Mention staging here?
+If you have git push ability, make sure that you @emph{remove}
+your patch (with @command{git rebase} or @command{git reset})
+before pushing other stuff.
+
+@c don't make this one an @example; we don't want to make it easy
+@c for people to use this accidently
+Notifications of patches are automatically added to our issue
+tracker to reduce the chance of patches getting lost. To suppress
+this (not recommended), add the @code{-n / --no-code-issue}
+option.
+
+@item
+@strong{Separate branch}: (complicated option)
+
+Ensure your changes are committed in a separate branch, which should
+differ from the reference branch to be used (usually
+@code{origin/master}) by just the changes to be uploaded. Checkout the
+branch with the changes:
+
+@example
+git checkout some-branch-with-changes
+@end example
+
+If the reference branch is to be @code{origin/master}, ensure that the
+branch containing the changes is up-to-date with it. Use
+@command{git rebase} or @command{git pull -r} to rebase the branch to
+the head of @code{origin/master}. For example:
+
+@example
+git pull -r origin master
+@end example
+
+Finally, start the upload by entering:
+
+@example
+git-cl upload <reference SHA1 ID>
+@end example
+
+@noindent
+where <reference SHA1 ID> is the SHA1 ID of the commit to be used
+as a reference source for the patch. Generally, this will be the
+SHA1 ID of origin/master, and in that case you can just use the command:
+
+@example
+git-cl upload origin/master
+@end example
+
+@end itemize
+
+First you will see a terminal editor where you can edit the
+message that will accompany your patch. @command{git-cl} will
+respect the @env{EDITOR} environment variable if defined,
+otherwise it will use @command{vi} as the default editor.
+
+After prompting for your Google email address and password, the
+patch set will be posted to Rietveld, and you will be given a URL
+for your patch.
+
+@warning{Some installations of git-cl fail when uploading a patch
+with certain filename extensions. If this happens, it can
+generally be fixed by editing the list of exceptions at top of
+@file{git-cl.py}.}
+
+@subsubheading Announcing your patch set
+
+You should then announce the patch by logging into the code review
+issue webpage and using @qq{Publish + Mail Comments} to add a
+(mostly bogus) comment to your issue. The text of your comment
+will be sent to our developer mailing list.
+
+@warning{There is no automatic notification of a new patch; you
+must add a comment yourself.}
+
+@subsubheading Revisions
+
+As revisions are made in response to comments, successive patch sets
+for the same issue can be uploaded by reissuing the git-cl command
+with the modified branch checked out.
+
+Sometimes in response to comments on revisions, the best way to
+work may require creation of a new branch in git. In order to
+associate the new branch with an existing Rietveld issue,
+the following command can be used:
+
+@example
+git-cl issue issue-number
+@end example
+
+@noindent
+where @code{issue-number} is the number of the existing Rietveld
+issue.
+
+@subsubheading Resetting git-cl
+
+If @command{git-cl} becomes confused, you can @qq{reset} it by
+running:
+
+@example
+git-cl issue 0
+@end example
+
+
+@node The patch review cycle
+@subsection The patch review cycle
+
+Your patch will be available for reviews for the next few hours or
+days. Three times a week, patches with no known problems are
+gathered into a @qq{patch countdown} and their status changed to
+@code{patch-countdown}. The countdown is a 48-hour waiting period
+in which any final reviews or complaints should be made.
+
+During the countdown, your patch may be set to
+@code{patch-needs_work}, indicating that you should fix something
+(or at least discuss why the patch needs no modification). If no
+problems are found, the patch will be set to @code{patch-push}.
+
+Once a patch has @code{patch-push}, it should be sent to your
+mentor for uploading. If you have git push ability, look at
+@ref{Pushing to staging}.
+
+@itemize
+
+@item
+Patches get added to the tracker and to Rietveld by the @qq{git-cl} tool, with
+a status of @qq{patch-new}.
+
+@item
+The automated tester, Patchy, verifies that the patch can be applied
+to current master. By default, it checks that the patch allows @code{make}
+and @code{make test} to complete successfully. It can also be configured to
+check that @code{make doc} is successful. If it passes, Patchy changes the
+status to @qq{patch-review} and emails the developer list. If the patch
+fails, Patchy sets it to @qq{patch-needs_work} and notifies the developer list.
+
+@item
+The Patch Meister reviews the tracker periodically, to list patches
+which have been on review for at least 24 hours. The list is found at
+
+@smallexample
+@uref{http://code.google.com/p/lilypond/issues/list?can=2&q=label:patch%20patch=review&sort=modified+patch&colspec=ID%20Type%20Status%20Priority%20Owner%20Patch%20Summary%20Modified}
+@end smallexample
+
+@item
+For each patch, the Handler reviews any discussion on the tracker
+and on Rietveld, to determine whether the patch can go forward. If
+there is any indication that a developer thinks the patch is not
+ready, the Handler marks it @qq{patch-needs_work} and makes a comment
+regarding the reason, referring to the Rietveld item if needed.
+
+@item
+Patches with explicit approval, or at least no negative comment, can
+be updated to @qq{patch-countdown}. When saving the tracker item,
+clear the @qq{send email} box to prevent sending notification for
+each patch.