export PS1="\u@\h \w\$(__git_ps1)$ "
@end verbatim
-If you are not using LilyDev, you may need to install the
-additional @code{git-completion} package, but it is definitely
-worth it.
+You may need to install the additional @code{bash-completion}
+package, but it is definitely worth it. After installation
+you must log out, and then log back in again to enable it.
@subsubheading Technical details
@menu
* lilypond-extra::
* Grand Unified Builder (GUB)::
-* lilypad::
+* LilyPad::
* yet more repositories::
@end menu
@end example
-@node lilypad
-@unnumberedsubsubsec lilypad
+@node LilyPad
+@unnumberedsubsubsec LilyPad
Our binary releases on MacOS X and Windows contain a lightweight
-text editor. This code is here:
+text editor.
+
+To make any modifications the Windows editor, you will need to do the
+following:
+
+@enumerate
+@item
+Clone the git repository from @code{https://github.com/gperciva/lilypad}
+
+@item
+Make changes to the source, and check it compiles. In a Windows environment
+@code{MinGW} provides both a @code{Git} installation and a @code{gcc}
+compiler. This can be obtained from @code{http://www.mingw.org/}
+
+@item
+Update the version which is contained in the @file{rsrc.rc}. Check
+this compiles, too.
+
+@item
+Commit the changes with an informative commit message.
+
+@item
+Push the changes to github. You will need to use syntax similiar to this:
@example
-https://github.com/gperciva/lilypad
+git push https://UserName@@github.com/gperciva/lilypad.git
@end example
+You will need to have push access to the git repository for this to be
+successful.
+
+@item
+Make a tarball of the source code to be used by GUB by pulling the updated
+repository from GitHub. Ensure that the tarball has the correct Version
+number.
+
+@item
+Copy the tarball to @code{http://lilypond.org/download/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.
+
+@item
+Update GUB to make it use the new tarball by editing
+@file{gub/specs/lilypad.py} and changing the @code{source =} line to point to
+the new source.
+
+@item
+Push this updated @file{lilypad.py} version to the GUB repository on GitHub.
+
+@item
+Test the changes with a new GUB compile.
+
+@end enumerate
@node yet more repositories
@unnumberedsubsubsec yet more repositories
and @command{upload.py} scripts in one of your PATH
directories (such as @file{$HOME/bin}).
-In Ubuntu (and LilyDev), you can add directories to PATH
+In GNU/Linux you can add directories to PATH
by adding this line to a hidden file @file{.bashrc},
located in your home directory:
@enumerate
@item
-You must have a google account; please create one if you do not
+You must own a Google account login; please create one if you do not
have one already.
-Note that a google account does not need to be a gmail account; you can
-use any email address for your google account when you sign up.
+@noindent
+Note that a google account does not need to be a Gmail account; you can
+use @emph{any} email address for your google account when you sign up.
+
+@warning{In order for @code{git-cl} to work as expected, your Google
+Account Settings must have the @q{Access for less secure apps} set to
+@q{Allowed}. This is normally the default setting.}
@item
Move into the top source directory and then configure @command{git
@subsubheading Uploading patch set
+This section assumes that you have already configured the
+@command{git-cl} @q{helper-script}. See @ref{git-cl}.
+
@warning{Unless you are familiar with branches, only work on one
set of changes at once.}
@itemize
@item
-@strong{Master branch}: (easy option, and used in @command{lily-git.tcl})
+@strong{Master branch}: (easy option)
If you added your patch to @code{master}, then:
@example
git pull -r
-git cl upload origin/master
+git-cl upload origin/master
@end example
@c Mention staging here?
@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 by just the
-changes to be uploaded. If the reference branch is to be
-origin/master, ensure this is up-to-date. If necessary, use git
-rebase to rebase the branch containing the changes to the head of
-origin/master. Finally, check out branch with the changes and
-enter the command:
+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>