@example
git fetch
git rebase origin/staging dev/cg~0
-gitk HEAD
+gitk HEAD
@end example
@warning{Do not skip the @command{gitk} step; a quick 5-second
number.
@item
-Copy the tarball to @code{http://lilypond.org/download/gub-sources/lilypad/}.
+Copy the tarball to @code{http://lilypond.org/downloads/gub-sources/lilypad/}.
You will need to have SSH access to @code{lilypond.org}. If you do not, contact
the Release Manager via the lilypond-devel mailing list.
@end example
Commit messages often start with a short prefix describing the
-general location of the changes. If a commit affects 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
+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. Commits that affect the
+@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 the other languages. Also, changes
-to a single file are often prefixed with the name of the file
-involved. Visit the links listed in @ref{Understanding commits}
-for examples.
+@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
proper fix usually involves rewriting the staging branch and is best
left to core developers after discussion on the developer list.
+Before pushing to staging it is a good practice to check whether
+staging is ahead of master, and if so, wait until master has caught up
+with staging before pushing. This simplifies things if changes to
+staging have to be backed out for some reason. To check whether
+master has caught up with staging you can look at the git web interface
+on savannah, or do:
+
+@example
+git fetch
+gitk
+@end example
+
+and check that @code{origin/master} is at the same commit as
+@code{origin/staging}. Another option is to see if any commits are
+listed when you do:
+
+@example
+git fetch
+git log origin/master..origin/staging
+@end example
+
@subsubheading If your work is in a patch file
Assuming that your patch is in a file called
-@file{0001-my-patch.patch}, and you are currently on git master,
-do:
+@file{0001-my-patch.patch} (see @ref{Patches}), and you are currently
+on git master, do:
@example
git checkout staging
@subsubheading If your work is in a branch
-If you are working on branches and your work in is
+If you are working on branches and your work is in
@code{my_branch_name}, then do:
@example
-git checkout staging
-git pull -r
-git merge my_branch_name
+git checkout my_branch_name
+git pull -r origin staging
+@end example
+
+This will rebase your branch on @code{origin/staging}. At this point
+git will let you know if there are any conflicts. If so, resolve them
+before continuing:
+
+@example
gitk
-git push origin staging
+git push origin HEAD:staging
@end example
@warning{Do not skip the @command{gitk} step; a quick 5-second
check of the visual history can save a great deal of frustration
-later on. You should see that @code{staging} is only ahead of
+later on. You should see that @code{my_branch_name} is only ahead of
@code{origin/staging} by the commits from your branch.}