1 @c -*- coding: us-ascii; mode: texinfo; -*-
2 @node Starting with git
3 @chapter Starting with git
5 To complete or present in another form the introduction to Git usage
6 in this chapter, it may be a good idea to look for Git documentation
7 at @uref{http://git-scm.com/documentation},
10 * Getting the source code::
11 * Updating the source code::
12 * Sharing your changes::
13 * Advanced git stuff::
15 * Development inside VirtualBox (compiling on Windows)::
19 @node Getting the source code
20 @section Getting the source code
24 * Git user configuration::
26 * Documentation translations source code::
28 * Other locations for git::
31 @node Git introduction
32 @subsection Git introduction
34 The source code is kept in a Git respository. This allows us to
35 track changes to files, and for multiple people to work on the
36 same set of files efficiently.
38 After downloading the source code, it is important to update the
39 repository by @ref{Updating the source code}.
41 @warning{These instructions assume that you are using the
42 command-line version of Git 1.5 or higher. Windows users should
43 skip to @ref{Git on Windows}.}
46 @node Git user configuration
47 @subsection Git user configuration
49 Some useful cofiguration can be performed automatically; cut and
50 paste the following section:
53 git config --global color.ui auto
54 git config --global branch.autosetuprebase always
57 To configure git to automatically use your name and email address
58 for commits and patches, edit the below lines by changing all the
62 git config --global user.name "MYNAME"
63 git config --global user.email MYEMAIL@@EXAMPLE.NET
67 @node Main source code
68 @subsection Main source code
70 To get the main source code and documentation,
72 @c WARNING: when updating the commands below, please
73 @c update the other flavors in the two next nodes
74 @c and in Introduction to Git concepts
76 mkdir lilypond; cd lilypond
78 git remote add -f -t master -m master origin git://git.sv.gnu.org/lilypond.git/
79 git checkout -b master origin/master
83 @node Documentation translations source code
84 @subsection Documentation translations source code
86 To translate the documentation (@emph{not} the website),
87 FIXME: when website is integrated, modify this.
90 mkdir lilypond-translation; cd lilypond-translation
92 git remote add -f -t lilypond/translation -m lilypond/translation origin git://git.sv.gnu.org/lilypond.git/
93 git checkout -b lilypond/translation origin/lilypond/translation
98 @subsection Other branches
100 Most contributors will never need to touch the other branches. If
101 you wish to do so, you will need more familiarity with git.
105 @item @code{dev/XYZ}:
106 These branches are for individual developers. They store code
107 which is not yet stable enough to be added to the @code{master}
110 @item @code{stable/XYZ}:
111 The branches are kept for archival reasons.
115 Another item of interest might be the Grand Unified Builder, our
116 cross-platform building tool. Since it is used by projects as
117 well, it is not stored in our gub repository. For more info, see
118 @uref{http://lilypond.org/gub}. The git location is:
121 http://github.com/janneke/gub
125 @node Other locations for git
126 @subsection Other locations for git
128 If you have difficulty connecting to most of the repositories
129 listed in earlier sections, try:
132 http://git.sv.gnu.org/r/lilypond.git
133 git://git.sv.gnu.org/lilypond.git
134 ssh://git.sv.gnu.org/srv/git/lilypond.git
137 Using HTTP protocol is slowest, so it is not recommended unless both
138 SSH and Git protocols fail, which happens e.g. if you connect to
139 internet through a router that filters out Git and/or SSH connections.
143 @node Updating the source code
144 @section Updating the source code
147 * Importance of updating::
149 * Resolving conflicts::
153 @node Importance of updating
154 @subsection Importance of updating
156 In a large project like LilyPond, contributors sometimes edit the same
157 file at the same time. As long as everybody updates their version of
158 the file with the most recent changes (@emph{pulling}), there are
159 generally no problems with this multiple-person editing. However,
160 big problems can arise if you do not pull before attempting to
161 commit. If this occurs, see @ref{Resolving conflicts}.
165 @subsection Updating command
167 Whenever you are asked to pull, it means you should update your
168 local copy of the repository with the changes made by others on
169 the remote @code{git.sv.gnu.org} repository:
176 The @code{-r} option is short for @code{--rebase}. If you don't
177 want to type @code{-r} every time, add @code{rebase = true} to the
178 master branch in your @file{.git/config}, like so:
183 merge = refs/heads/master
188 @node Resolving conflicts
189 @subsection Resolving conflicts
191 Occasionally an update may result in conflicts -- this happens
192 when you and somebody else have modified the same part of the same
193 file and git cannot figure out how to merge the two versions
194 together. When this happens, you must manually merge the two
197 If you need some documentation to understand and resolve conflicts,
198 see paragraphs @emph{How conflicts are presented} and @emph{How to
199 resolve conflicts} in @command{git merge} man page.
202 @node Sharing your changes
203 @section Sharing your changes
206 * Producing a patch::
207 * Committing directly::
211 @node Producing a patch
212 @subsection Producing a patch
214 Once you have finished editing your files, checked that your changes
215 meet the @ref{Code style}, and/or @ref{Documentation policy}, properly
216 set up your name and email in @ref{Git user configuration}, and
217 checked that the entire thing compiles, you may:
221 git format-patch origin
224 The commit should include a brief message describing the change.
225 This consists of a one-line summary describing the change, and
226 if necessary a blank line followed by several lines giving the
230 Did household chores.
232 I hung up the wet laundry and then washed the car. I also
233 vacuumed the floors, rinsed the dirty dishes, fed the cat, and
234 recalibrated the temporal flux machine.
237 If the change is to the documentation only then the one-line
238 summary should be prefixed with @qq{Docs: }.
240 If you added a file to the source code, you must add it to git
248 (and possibly modify the @file{GNUmakefile})
250 These commands will produce one or more files named
251 @file{0001-xyz}, @file{0002-abc}, etc. in the top directory of the
252 git tree. Send an email to @email{lilypond-devel@@gnu.org} with
253 these files attached, and a developer will review and apply the
254 patches to the main repository.
257 @node Committing directly
258 @subsection Committing directly
260 Most contributors do not have permission to commit directly. If you
261 do, make sure you have set up your name and email in @ref{Git user
262 configuration}, then edit @file{.git/config}: change the line
265 url = git://git.sv.gnu.org/lilypond.git/
272 url = ssh://@var{user}@@git.sv.gnu.org/srv/git/lilypond.git
276 where @var{user} is your login name on Savannah.
278 If you have not already done so, you should generate and upload a
279 SSH key: open @uref{https://savannah.gnu.org/my/} in your browser,
280 go to @q{Account Configuration}, then to something like
281 @q{Edit SSH Keys}, and follow the instructions on that page.
289 Note that recent versions of Git (Git 1.6.3 or later) will issue a
290 big warning if the above command is used. The simplest solution
291 is to add a new section to @file{.git/config} that looks like
300 Then @code{git push origin} will work as before. For more
301 details, consult the @code{git push} man page.
304 @node Advanced git stuff
305 @section Advanced git stuff
307 @warning{This section is not necessary for normal contributors;
308 these commands are presented for information for people interested
309 in learning more about git.}
312 It is possible to work with several branches on the same local Git
313 repository; this is especially useful for translators who may have to
314 deal with both @code{lilypond/translation} and a stable branch,
315 e.g. @code{stable/2.12}.
317 Some Git commands are introduced first, then a workflow with several
318 Git branches of LilyPond source code is presented.
321 * Introduction to Git concepts::
322 * Git commands for managing several branches::
323 * Working on LilyPond sources with several branches::
325 * Applying git patches::
326 * Reverting all local changes::
330 @node Introduction to Git concepts
331 @subsection Introduction to Git concepts
333 A bit of Git vocabulary will be explained below. The following is
334 just introduction material; for better understanding of Git concepts,
335 you are invited to read further documentation, especially Git
336 Community Book at @uref{http://book.git-scm.com/}.
338 The @code{git pull origin} command above is just a shortcut for this
342 git pull git://git.sv.gnu.org/lilypond.git/ @var{branch}:origin/@var{branch}
346 where @code{@var{branch}} is typically @code{master}, @code{web} or
347 @code{lilypond/translation}; if you do not know or remember, see
348 @ref{Getting the source code} to remember which commands you issued or
349 which source code you wanted to get.
351 A @emph{commit} is a set of changes made to the sources; it also
352 includes the committish of the parent commit, the name and e-mail of
353 the @emph{author} (the person who wrote the changes), the name and
354 e-mail of the @emph{committer} (the person who brings these changes
355 into the Git repository), and a commit message.
357 A @emph{committish} is the SHA1 checksum of a commit, a number made of
358 40 hexadecimal digits, which acts as the internal unique identifier
359 for this commit. To refer to a particular revision, don't use vague
360 references like the (approximative) date, simply copy and paste the
363 A @emph{branch} is nothing more than a pointer to a particular commit,
364 which is called the @emph{head} of the branch; when referring to a
365 branch, one often acutally thinks about its head and the ancestor
368 Now we will explain the two last commands you used to get the source
369 code from Git -- see @ref{Getting the source code}.
372 git remote add -f -t @var{branch} -m @var{branch} origin git://git.sv.gnu.org/lilypond.git/
373 git checkout -b @var{branch} origin/@var{branch}
376 The @command{git remote} has created a branch called
377 @code{origin/@var{branch}} in your local Git repository. As this
378 branch is a copy of the remote branch web from git.sv.gnu.org LilyPond
379 repository, it is called a @emph{remote branch}, and is meant to track
380 the changes on the branch from git.sv.gnu.org: it will be updated
381 every time you run @command{git pull origin} or @command{git fetch
384 The @command{git checkout} command has created a branch named
385 @code{@var{branch}}. At the beginning, this branch is identical to
386 @code{origin/@var{branch}}, but it will differ as soon as you make
387 changes, e.g. adding newly translated pages or editing some
388 documentation or code source file. Whenever you pull, you merge the
389 changes from @code{origin/@var{branch}} and @code{@var{branch}} since
390 the last pulling. If you do not have push (i.e. @qq{write}) access on
391 git.sv.gnu.org, your @code{@var{branch}} will always differ from
392 @code{origin/@var{branch}}. In this case, remember that other people
393 working like you with the remote branch @code{@var{branch}} of
394 git://git.sv.gnu.org/lilypond.git/ (called @code{origin/@var{branch}}
395 on your local repository) know nothing about your own
396 @code{@var{branch}}: this means that whenever you use a committish or
397 make a patch, others expect you to take the latest commit of
398 @code{origin/@var{branch}} as a reference.
400 Finally, please remember to read the man page of every Git command you
401 will find in this manual in case you want to discover alternate
402 methods or just understand how it works.
405 @node Git commands for managing several branches
406 @subsection Git commands for managing several branches
408 @subsubheading Listing branches and remotes
410 You can get the exact path or URL of all remotes with
417 To list Git branches on your local repositories, run
420 git branch # list local branches only
421 git branch -r # list remote branches
422 git branch -a # list all branches
426 @subsubheading Checking out branches
428 To know the currently checked out branch, i.e. the branch whose source
429 files are present in your working tree, read the first line of the
437 The currently checked out branch is also marked with an asterisk in
438 the output of @command{git branch}.
440 You can check out another branch @code{@var{other_branch}}, i.e. check
441 out @code{@var{other_branch}} to the working tree, by running
444 git checkout @var{other_branch}
447 Note that it is possible to check out another branch while having
448 uncommitted changes, but it is not recommended unless you know what
449 you are doing; it is recommended to run @command{git status} to check
450 this kind of issue before checking out another branch.
453 @subsubheading Merging branches
455 To merge branch @code{@var{foo}} into branch @code{@var{bar}}, i.e. to
456 @qq{add} all changes made in branch @code{@var{foo}} to branch
457 @code{@var{bar}}, run
460 git checkout @var{bar}
464 If any conflict happens, see @ref{Resolving conflicts}.
466 There are common usage cases for merging: as a translator, you will
467 often want to merge @code{master} into @code{lilypond/translation}; on
468 the other hand, the Translations meister wants to merge
469 @code{lilypond/translation} into @code{master} whenever he has checked
470 that @code{lilypond/translation} builds successfully.
473 @node Working on LilyPond sources with several branches
474 @subsection Working on LilyPond sources with several branches
476 @subsubheading Fetching new branches from git.sv.gnu.org
478 To fetch and check out a new branch named @code{@var{branch}} on
479 git.sv.gnu.org, run from top of the Git repository
482 git config --add remote.origin.fetch +refs/heads/@var{branch}:refs/remotes/origin/@var{branch}
483 git checkout --track -b @var{branch} origin/@var{branch}
486 After this, you can pull @code{@var{branch}} from git.sv.gnu.org with
492 Note that this command generally fetches all branches you added with
493 @command{git remote add} (when you initialized the repository) or
494 @command{git config --add}, i.e. it updates all remote branches from
495 remote @code{origin}, then it merges the remote branch tracked by
496 current branch into current branch. For example, if your current
497 branch is @code{master} --- which is the case if you got the sources
498 with the commands described in @ref{Main source code} and did not
499 issue any @command{git checkout} command --- @code{origin/master} will
500 be merged into @code{master}.
503 @subsubheading Local clones, or having several working trees
505 If you play with several Git branches, e.g. @code{master},
506 @code{lilypond/translation}, @code{stable/2.12}), you may want to have
507 one source and build tree for each branch; this is possible with
508 subdirectories of your local Git repository, used as local cloned
509 subrepositories. To create a local clone for the branch named
510 @code{@var{branch}}, run
513 git checkout @var{branch}
514 git clone -l -s -n . @var{subdir}
519 Note that @code{@var{subdir}} must be a directory name which does not
520 already exist. In @code{@var{subdir}}, you can use all Git commands
521 to browse revisions history, commit and uncommit changes; to update
522 the cloned subrepository with changes made on the main repository, cd
523 into @code{@var{subdir}} and run @command{git pull}; to send changes
524 made on the subrepository back to the main repository, run
525 @command{git push} from @code{@var{subdir}}. Note that only one
526 branch (the currently checked out branch) is created in the
527 subrepository by default; it is possible to have several branches in a
528 subrepository and do usual operations (checkout, merge, create,
529 delete...) on these branches, but this possibility is not detailed
532 When you push @code{@var{branch}} from @code{@var{subdir}} to the main
533 repository, and @code{@var{branch}} is checked out in the main
534 repository, you must save uncommitted changes (see @command{git
535 stash}) and do @command{git reset --hard} in the main repository in
536 order to apply pushed changes in the working tree of the main
543 The commands above don't only bring you the latest version of the
544 sources, but also the full history of revisions (revisons, also
545 called commits, are changes made to the sources), stored in the
546 .git directory. You can browse this history with
549 git log # only shows the logs (author, committish and commit message)
550 git log -p # also shows diffs
551 gitk # shows history graphically
554 @warning{The @code{gitk} command may require a separate @code{gitk} package,
555 available in the appropriate distribution's repositories.}
558 @node Applying git patches
559 @subsection Applying git patches
561 Well-formed git patches created with @code{git format-patch}
562 should be committed with the following command:
568 Patches created without @code{git format-patch} can be applied in
569 two steps. The first step is to apply the patch to the working
573 git apply @var{patch}
577 The second step is to commit the changes and give credit to the
578 author of the patch. This can be done with the following command:
581 git commit -a --author="First Last <user@@example.net>"
585 @node Reverting all local changes
586 @subsection Reverting all local changes
588 Sometimes git will become hopelessly confused, and you just want
589 to get back to a known, stable state. This command destroys any
590 local changes you have made, but at least you get back to the
591 current online version:
594 git reset --hard origin/master
599 @section Git on Windows
601 @c Some of this may duplicate stuff in other sections
602 @c Clear this up later -td
604 @subsection Background to nomenclature
606 Git is a system for tracking the changes made to source files by
607 a distributed set of editors. It is designed to work without a
608 master repository, but we have chosen to have a master respository
609 for LilyPond files. Editors hold local copies of the master
610 repository together with any changes they have made locally. Local
611 changes are held in a local @q{branch}, of which there may be
612 several, but these instructions assume you are using just one. The
613 files visible in the local repository always correspond to those
614 on the currently @q{checked out} local branch.
616 Files are edited on a local branch, and in that state the
617 changes are said to be @q{unstaged}. When editing is complete, the
618 changes are moved to being @q{staged for commit}, and finally the
619 changes are @q{committed} to the local branch. Once
620 committed, the changes are given a unique reference number called the
621 @q{Committish} which identifies them to Git. Such committed changes
622 can be sent to the master repository by @q{pushing} them (if you
623 have write permission) or by sending them by email to someone who
624 has, either complete or as a @q{diff} or @q{patch} (which send
625 just the differences from master).
627 @subsection Installing git
630 @uref{http://code.google.com/p/msysgit/downloads/list}
631 (note, not msysGit, which is for Git developers and not PortableGit,
632 which is not a full git installation) and
635 Note that most users will not need to install SSH. That is not
636 required until you have been granted direct push permissions to
637 the master git repository.
639 Start Git by clicking on the desktop icon.
640 This will bring up a command line bash shell. This may be
641 unfamiliar to Windows users. If so, follow these
642 instructions carefully. Commands are entered at a $ prompt
643 and are terminated by keying a newline.
645 @subsection Initialising Git
647 Decide where you wish to place your local Git repository,
648 creating the folders in Windows as necessary. Here we
649 call the folder to contain the repository [path]/Git.
650 You will need to have space for around 150Mbytes.
652 Start the Git bash shell by clicking on the desk-top icon installed
659 to position the shell at your new Git repository.
661 Note: if [path] contains folders with names containing
674 to initialize your Git repository.
676 Then type (all on one line; the shell will wrap automatically)
679 git remote add -f -t master origin git://git.sv.gnu.org/lilypond.git
682 to download the lilypond master files.
684 @warning{Be patient! Even on a broadband connection this can take
685 10 minutes or more. Wait for lots of [new tag] messages
688 We now need to generate a local copy of the downloaded files
689 in a new local branch. Your local branch needs to have a
690 name, here we call it @q{lily-local} - you may wish to make up
696 git checkout -b lily-local origin/master
699 to create the lily-local branch containing the local copies of the
700 master files. You will be advised your local branch has been set
701 up to track the remote branch.
703 Return to Windows Explorer and look in your Git repository. You
704 should see lots of folders. For example, the LilyPond documentation
705 can be found in Git/Documentation/user.
707 Terminate the Git bash shell by typing @code{exit}.
711 Almost all subsequent work will use the Git Graphical User
712 Interface, which avoids having to type command line
713 commands. To start Git GUI first start the Git bash shell by
714 clicking on the desktop icon, and type
721 The Git GUI will open in a new window. It contains four panels
722 and 7 pull-down menus. At this stage do not use any of the
723 commands under Branch, Commit, Merge or Remote. These will
726 The two panels on the left contain the names of files which
727 you are in the process of editing (Unstaged Changes), and
728 files you have finished editing and have staged ready for
729 committing (Staged Changes). At this stage these panels will
730 be empty as you have not yet made any changes to any file.
731 After a file has been edited and saved the top panel on the right
732 will display the differences between the edited file selected
733 in one of the panels on the left and the last version committed.
735 The final panel at bottom right is used to enter a descriptive
736 message about the change before committing it.
738 The Git GUI is terminated by entering CNTL-Q while it is the
739 active window or by clicking on the usual Windows close-window
742 @subsection Personalising your local git repository
744 Open the Git GUI, click on
750 and enter your name and email address in the
751 left-hand (Git Repository) panel. Leave everything
752 else unchanged and save it.
754 Note that Windows users must leave the default setting for line
755 endings unchanged. All files in a git repository must have lines
756 terminated by just a LF, as this is required for Merge to work, but
757 Windows files are terminated by CRLF by default. The git default
758 setting causes the line endings of files in a Windows git repository
759 to be flipped automatically between LF and CRLF as required. This
760 enables files to be edited by any Windows editor without causing
761 problems in the git repository.
763 @subsection Checking out a branch
765 At this stage you have two branches in your local repository,
766 both identical. To see them click on
772 You should have one local branch called @w{lily-local} and one
773 tracking branch called @w{origin/master}. The latter is your
774 local copy of the @w{remote/origin/master} branch in the master
775 LilyPond repository. The @w{lily-local} branch is where you
776 will make your local changes.
778 When a particular branch is selected, i.e., checked out, the
779 files visible in your repository are changed to reflect the
780 state of the files on that branch.
782 @subsection Updating files from @w{remote/origin/master}
784 Before starting the editing of a file, ensure your local branches
785 contain the latest version in @w{remote/origin/master} by first
789 Remote -> Fetch from -> origin
795 This will place the latest version of every file, including all the
796 changes made by others,
797 into the @q{origin/master} branch of the tracking branches
798 in your git repository. You can see these files by checking
799 out this branch. This will not affect any files you have
800 modified in your local branch.
802 You then need to merge these fetched files into your local
803 branch by clicking on
810 and if necessary select the local branch into which the merge
813 Note that a merge cannot be completed if there are any local
814 uncommitted changes on the lily-local branch.
816 This will update all the files in that branch to reflect the
817 current state of the @w{origin/master} branch. If any of the
818 changes conflict with changes you have made yourself recently
819 you will be notified of the conflict (see below).
821 @subsection Editing files
823 First ensure your lily-local branch is checked out, then
824 simply edit the files in your local Git repository with your
825 favourite editor and save them back there. If any file contains
826 non-ASCII characters ensure you save it in UTF-8 format. Git will
827 detect any changes whenever you restart Git GUI and the file names
828 will then be listed in the Unstaged Changes panel.
829 Or you can click the Rescan button to refresh the panel
830 contents at any time. You may break off and resume at
833 The changes you have made may be displayed in diff form
834 in the top right-hand panel by clicking on the name in
837 When your editing is complete, move the files from being
838 Unstaged to Staged by clicking the document symbol to
839 the left of each name. If you change your mind it can
840 be moved back by clicking on the ticked box to the
843 Finally the changes you have made may be committed to
844 your lily-local branch by entering a brief message in
845 the Commit Message box and clicking the Commit button.
847 If you wish to amend your changes after a commit has been
848 made, the original version and the changes you made in that
849 commit may be recovered by selecting
852 Commit -> Amend Last Commit
856 or by checking the Amend Last Commit radio button at bottom left.
857 This will return the changes to the Staged state, so further
858 editing made be carried out within that commit. This must only be
859 done @emph{before} the changes have been Pushed or sent to your
860 mentor for Pushing - after that it is too late and corrections
861 have to be made as a separate commit.
864 @subsection Sending changes to remote/origin/master
866 If you do not have write access to @w{remote/origin/master} you will
867 need to send your changes by email to someone who does.
869 First you need to create a diff or patch file containing
870 your changes. To create this, the file must first be
871 committed. Then terminate the Git GUI. In the
872 git bash shell first cd to your Git repository with
878 if necessary, then produce the patch with
881 git format-patch origin
884 This will create a patch file for all the locally committed files
885 which differ from @w{origin/master}. The patch file can be found
886 in [path]/Git and will have a name formed from n and the commit
889 @subsection Resolving merge conflicts
891 As soon as you have committed a changed file your local
892 branch has diverged from @w{origin/master}, and will
893 remain diverged until your changes have been committed
894 in @w{remote/origin/master} and Fetched back into your
895 @w{origin/master}. Similarly, if a new commit has been made
896 to @w{remote/origin/master} by someone else and Fetched, your
897 lily-local branch is divergent. You can detect a divergent
898 branch by clicking on
901 Repository -> Visualise all branch history
904 This opens up a very useful new window called @q{gitk}.
905 Use this to browse all the commits made by others.
907 If the diagram at top left of the resulting window
908 does not show your branch's tag on the same node as
909 the @w{remote/origins/master} tag your branch has diverged from
910 @w{origin/master}. This is quite normal if files you have modified
911 yourself have not yet been Pushed to @w{remote/origin/master} and
912 Fetched, or if files modified and committed by others have been
913 Fetched since you last Merged @w{origin/master} into your lily-local
916 If a file being merged from @w{origin/master} differs from
917 one you have modified in a way that cannot be resolved
918 automatically by git, Merge will report a Conflict
919 which you must resolve by editing the file to create the
920 version you wish to keep.
922 This could happen if the person updating @w{remote/origin/master}
923 for you has added some changes of his own before
924 committing your changes to @w{remote/origin/master}, or if someone
925 else has changed the same file since you last
926 fetched the file from @w{remote/origin/master}.
928 Open the file in your editor and look for sections which
929 are delimited with ...
931 [to be completed when I next have a merge conflict to be
932 sure I give the right instructions -td]
935 @subsection Other actions
937 The instructions above describe the simplest way of using
938 git on Windows. Other git facilities which may usefully
939 supplement these include
943 @item Using multiple local branches (Create, Rename, Delete)
944 @item Resetting branches
945 @item Cherry-picking commits
946 @item Pushing commits to @w{remote/origin/master}
947 @item Using gitk to review history
951 Once familiarity with using git on Windows has been gained the
952 standard git manuals can be used to learn about these.
955 @node Development inside VirtualBox (compiling on Windows)
956 @section Development inside VirtualBox (compiling on Windows)