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}.}
45 Some sections of this guide will redirect to specific Git man pages;
46 however, if you think you need to understand more of Git, you might want
47 to read the book @uref{http://progit.org/,Pro Git}.
50 @node Git user configuration
51 @subsection Git user configuration
53 Some useful cofiguration can be performed automatically; cut and
54 paste the following section:
57 git config --global color.ui auto
58 git config --global branch.autosetuprebase always
61 To configure git to automatically use your name and email address
62 for commits and patches, edit the below lines by changing all the
66 git config --global user.name "MYNAME"
67 git config --global user.email MYEMAIL@@EXAMPLE.NET
71 @node Main source code
72 @subsection Main source code
74 To get the main source code and documentation,
76 @c WARNING: when updating the commands below, please
77 @c update the other flavors in the two next nodes
78 @c and in Introduction to Git concepts
80 mkdir lilypond; cd lilypond
82 git remote add -f -t master -m master origin git://git.sv.gnu.org/lilypond.git/
83 git checkout -b master origin/master
87 @node Documentation translations source code
88 @subsection Documentation translations source code
90 To translate the documentation (@emph{not} the website),
91 FIXME: when website is integrated, modify this.
94 mkdir lilypond-translation; cd lilypond-translation
96 git remote add -f -t lilypond/translation -m lilypond/translation origin git://git.sv.gnu.org/lilypond.git/
97 git checkout -b lilypond/translation origin/lilypond/translation
102 @subsection Other branches
104 Most contributors will never need to touch the other branches. If
105 you wish to do so, you will need more familiarity with git.
109 @item @code{dev/XYZ}:
110 These branches are for individual developers. They store code
111 which is not yet stable enough to be added to the @code{master}
114 @item @code{stable/XYZ}:
115 The branches are kept for archival reasons.
119 Another item of interest might be the Grand Unified Builder, our
120 cross-platform building tool. Since it is used by projects as
121 well, it is not stored in our gub repository. For more info, see
122 @uref{http://lilypond.org/gub}. The git location is:
125 http://github.com/janneke/gub
129 @node Other locations for git
130 @subsection Other locations for git
132 If you have difficulty connecting to most of the repositories
133 listed in earlier sections, try:
136 http://git.sv.gnu.org/r/lilypond.git
137 git://git.sv.gnu.org/lilypond.git
138 ssh://git.sv.gnu.org/srv/git/lilypond.git
141 Using HTTP protocol is slowest, so it is not recommended unless both
142 SSH and Git protocols fail, which happens e.g. if you connect to
143 internet through a router that filters out Git and/or SSH connections.
147 @node Updating the source code
148 @section Updating the source code
151 * Importance of updating::
153 * Resolving conflicts::
157 @node Importance of updating
158 @subsection Importance of updating
160 In a large project like LilyPond, contributors sometimes edit the same
161 file at the same time. As long as everybody updates their version of
162 the file with the most recent changes (@emph{pulling}), there are
163 generally no problems with this multiple-person editing. However,
164 big problems can arise if you do not pull before attempting to
165 commit. If this occurs, see @ref{Resolving conflicts}.
169 @subsection Updating command
171 Whenever you are asked to pull, it means you should update your
172 local copy of the repository with the changes made by others on
173 the remote @code{git.sv.gnu.org} repository:
180 The @code{-r} option is short for @code{--rebase}. If you don't
181 want to type @code{-r} every time, add @code{rebase = true} to the
182 master branch in your @file{.git/config}, like so:
187 merge = refs/heads/master
192 @node Resolving conflicts
193 @subsection Resolving conflicts
195 Occasionally an update may result in conflicts -- this happens
196 when you and somebody else have modified the same part of the same
197 file and git cannot figure out how to merge the two versions
198 together. When this happens, you must manually merge the two
201 If you need some documentation to understand and resolve conflicts,
202 see paragraphs @emph{How conflicts are presented} and @emph{How to
203 resolve conflicts} in @command{git merge} man page.
206 @node Sharing your changes
207 @section Sharing your changes
210 * Producing a patch::
211 * Committing directly::
215 @node Producing a patch
216 @subsection Producing a patch
218 Once you have finished editing your files, checked that your changes
219 meet the @ref{Code style}, and/or @ref{Documentation policy}, properly
220 set up your name and email in @ref{Git user configuration}, and
221 checked that the entire thing compiles, you may:
225 git format-patch origin
228 The commit should include a brief message describing the change.
229 This consists of a one-line summary describing the change, and
230 if necessary a blank line followed by several lines giving the
234 Did household chores.
236 I hung up the wet laundry and then washed the car. I also
237 vacuumed the floors, rinsed the dirty dishes, fed the cat, and
238 recalibrated the temporal flux machine.
241 If the change is to the documentation only then the one-line
242 summary should be prefixed with @qq{Docs: }.
244 If you added a file to the source code, you must add it to git
248 git add @var{FILENAME}
252 (and possibly modify the @file{GNUmakefile})
254 These commands will produce one or more files named @file{0001-xyz},
255 @file{0002-abc}, etc. in the top directory of the git tree. Send an
256 email to @email{lilypond-devel@@gnu.org} with these files attached, and
257 a developer will review and apply the patches to the main repository.
258 If your patch is some translation work, you may send it to
259 @email{translations@@lilynet.net} instead.
262 @node Committing directly
263 @subsection Committing directly
265 Most contributors do not have permission to commit directly. If you do,
266 make sure you have set up your name and email in @ref{Git user
267 configuration}, then edit @file{.git/config}: change the line
270 url = git://git.sv.gnu.org/lilypond.git/
277 url = ssh://@var{user}@@git.sv.gnu.org/srv/git/lilypond.git
281 where @var{user} is your login name on Savannah.
283 If you have not already done so, you should generate and upload a
284 SSH key: open @uref{https://savannah.gnu.org/my/} in your browser,
285 go to @q{Account Configuration}, then to something like
286 @q{Edit SSH Keys}, and follow the instructions on that page.
294 Note that recent versions of Git (Git 1.6.3 or later) will issue a
295 big warning if the above command is used. The simplest solution
296 is to add a new section to @file{.git/config} that looks like
305 Then @code{git push origin} will work as before. For more
306 details, consult the @code{git push} man page.
309 @node Advanced git stuff
310 @section Advanced git stuff
312 @warning{This section is not necessary for normal contributors;
313 these commands are presented for information for people interested
314 in learning more about git.}
317 It is possible to work with several branches on the same local Git
318 repository; this is especially useful for translators who may have to
319 deal with both @code{lilypond/translation} and a stable branch,
320 e.g. @code{stable/2.12}.
322 Some Git commands are introduced first, then a workflow with several
323 Git branches of LilyPond source code is presented.
326 * Introduction to Git concepts::
327 * Git commands for managing several branches::
328 * Working on LilyPond sources with several branches::
330 * Applying git patches::
331 * Reverting all local changes::
335 @node Introduction to Git concepts
336 @subsection Introduction to Git concepts
338 A bit of Git vocabulary will be explained below. The following is
339 just introduction material; for better understanding of Git concepts,
340 you are invited to read further documentation, especially Git
341 Community Book at @uref{http://book.git-scm.com/}.
343 The @code{git pull origin} command above is just a shortcut for this
347 git pull git://git.sv.gnu.org/lilypond.git/ @var{branch}:origin/@var{branch}
351 where @code{@var{branch}} is typically @code{master}, @code{web} or
352 @code{lilypond/translation}; if you do not know or remember, see
353 @ref{Getting the source code} to remember which commands you issued or
354 which source code you wanted to get.
356 A @emph{commit} is a set of changes made to the sources; it also
357 includes the committish of the parent commit, the name and e-mail of
358 the @emph{author} (the person who wrote the changes), the name and
359 e-mail of the @emph{committer} (the person who brings these changes
360 into the Git repository), and a commit message.
362 A @emph{committish} is the SHA1 checksum of a commit, a number made of
363 40 hexadecimal digits, which acts as the internal unique identifier
364 for this commit. To refer to a particular revision, don't use vague
365 references like the (approximative) date, simply copy and paste the
368 A @emph{branch} is nothing more than a pointer to a particular commit,
369 which is called the @emph{head} of the branch; when referring to a
370 branch, one often acutally thinks about its head and the ancestor
373 Now we will explain the two last commands you used to get the source
374 code from Git -- see @ref{Getting the source code}.
377 git remote add -f -t @var{branch} -m @var{branch} origin git://git.sv.gnu.org/lilypond.git/
378 git checkout -b @var{branch} origin/@var{branch}
381 The @command{git remote} has created a branch called
382 @code{origin/@var{branch}} in your local Git repository. As this
383 branch is a copy of the remote branch web from git.sv.gnu.org LilyPond
384 repository, it is called a @emph{remote branch}, and is meant to track
385 the changes on the branch from git.sv.gnu.org: it will be updated
386 every time you run @command{git pull origin} or @command{git fetch
389 The @command{git checkout} command has created a branch named
390 @code{@var{branch}}. At the beginning, this branch is identical to
391 @code{origin/@var{branch}}, but it will differ as soon as you make
392 changes, e.g. adding newly translated pages or editing some
393 documentation or code source file. Whenever you pull, you merge the
394 changes from @code{origin/@var{branch}} and @code{@var{branch}} since
395 the last pulling. If you do not have push (i.e. @qq{write}) access on
396 git.sv.gnu.org, your @code{@var{branch}} will always differ from
397 @code{origin/@var{branch}}. In this case, remember that other people
398 working like you with the remote branch @code{@var{branch}} of
399 git://git.sv.gnu.org/lilypond.git/ (called @code{origin/@var{branch}}
400 on your local repository) know nothing about your own
401 @code{@var{branch}}: this means that whenever you use a committish or
402 make a patch, others expect you to take the latest commit of
403 @code{origin/@var{branch}} as a reference.
405 Finally, please remember to read the man page of every Git command you
406 will find in this manual in case you want to discover alternate
407 methods or just understand how it works.
410 @node Git commands for managing several branches
411 @subsection Git commands for managing several branches
413 @subsubheading Listing branches and remotes
415 You can get the exact path or URL of all remotes with
422 To list Git branches on your local repositories, run
425 git branch # list local branches only
426 git branch -r # list remote branches
427 git branch -a # list all branches
431 @subsubheading Checking out branches
433 To know the currently checked out branch, i.e. the branch whose source
434 files are present in your working tree, read the first line of the
442 The currently checked out branch is also marked with an asterisk in
443 the output of @command{git branch}.
445 You can check out another branch @code{@var{other_branch}}, i.e. check
446 out @code{@var{other_branch}} to the working tree, by running
449 git checkout @var{other_branch}
452 Note that it is possible to check out another branch while having
453 uncommitted changes, but it is not recommended unless you know what
454 you are doing; it is recommended to run @command{git status} to check
455 this kind of issue before checking out another branch.
458 @subsubheading Merging branches
460 To merge branch @code{@var{foo}} into branch @code{@var{bar}}, i.e. to
461 @qq{add} all changes made in branch @code{@var{foo}} to branch
462 @code{@var{bar}}, run
465 git checkout @var{bar}
469 If any conflict happens, see @ref{Resolving conflicts}.
471 There are common usage cases for merging: as a translator, you will
472 often want to merge @code{master} into @code{lilypond/translation}; on
473 the other hand, the Translations meister wants to merge
474 @code{lilypond/translation} into @code{master} whenever he has checked
475 that @code{lilypond/translation} builds successfully.
478 @node Working on LilyPond sources with several branches
479 @subsection Working on LilyPond sources with several branches
481 @subsubheading Fetching new branches from git.sv.gnu.org
483 To fetch and check out a new branch named @code{@var{branch}} on
484 git.sv.gnu.org, run from top of the Git repository
487 git config --add remote.origin.fetch +refs/heads/@var{branch}:refs/remotes/origin/@var{branch}
488 git checkout --track -b @var{branch} origin/@var{branch}
491 After this, you can pull @code{@var{branch}} from git.sv.gnu.org with
497 Note that this command generally fetches all branches you added with
498 @command{git remote add} (when you initialized the repository) or
499 @command{git config --add}, i.e. it updates all remote branches from
500 remote @code{origin}, then it merges the remote branch tracked by
501 current branch into current branch. For example, if your current
502 branch is @code{master} --- which is the case if you got the sources
503 with the commands described in @ref{Main source code} and did not
504 issue any @command{git checkout} command --- @code{origin/master} will
505 be merged into @code{master}.
508 @subsubheading Local clones, or having several working trees
510 If you play with several Git branches, e.g. @code{master},
511 @code{lilypond/translation}, @code{stable/2.12}), you may want to have
512 one source and build tree for each branch; this is possible with
513 subdirectories of your local Git repository, used as local cloned
514 subrepositories. To create a local clone for the branch named
515 @code{@var{branch}}, run
518 git checkout @var{branch}
519 git clone -l -s -n . @var{subdir}
524 Note that @code{@var{subdir}} must be a directory name which does not
525 already exist. In @code{@var{subdir}}, you can use all Git commands
526 to browse revisions history, commit and uncommit changes; to update
527 the cloned subrepository with changes made on the main repository, cd
528 into @code{@var{subdir}} and run @command{git pull}; to send changes
529 made on the subrepository back to the main repository, run
530 @command{git push} from @code{@var{subdir}}. Note that only one
531 branch (the currently checked out branch) is created in the
532 subrepository by default; it is possible to have several branches in a
533 subrepository and do usual operations (checkout, merge, create,
534 delete...) on these branches, but this possibility is not detailed
537 When you push @code{@var{branch}} from @code{@var{subdir}} to the main
538 repository, and @code{@var{branch}} is checked out in the main
539 repository, you must save uncommitted changes (see @command{git
540 stash}) and do @command{git reset --hard} in the main repository in
541 order to apply pushed changes in the working tree of the main
548 The commands above don't only bring you the latest version of the
549 sources, but also the full history of revisions (revisons, also
550 called commits, are changes made to the sources), stored in the
551 .git directory. You can browse this history with
554 git log # only shows the logs (author, committish and commit message)
555 git log -p # also shows diffs
556 gitk # shows history graphically
559 @warning{The @code{gitk} command may require a separate @code{gitk} package,
560 available in the appropriate distribution's repositories.}
563 @node Applying git patches
564 @subsection Applying git patches
566 Well-formed git patches created with @code{git format-patch}
567 should be committed with the following command:
573 Patches created without @code{git format-patch} can be applied in
574 two steps. The first step is to apply the patch to the working
578 git apply @var{patch}
582 The second step is to commit the changes and give credit to the
583 author of the patch. This can be done with the following command:
586 git commit -a --author="First Last <user@@example.net>"
590 @node Reverting all local changes
591 @subsection Reverting all local changes
593 Sometimes git will become hopelessly confused, and you just want
594 to get back to a known, stable state. This command destroys any
595 local changes you have made, but at least you get back to the
596 current online version:
599 git reset --hard origin/master
604 @section Git on Windows
606 @c Some of this may duplicate stuff in other sections
607 @c Clear this up later -td
609 @subsection Background to nomenclature
611 Git is a system for tracking the changes made to source files by
612 a distributed set of editors. It is designed to work without a
613 master repository, but we have chosen to have a master respository
614 for LilyPond files. Editors hold local copies of the master
615 repository together with any changes they have made locally. Local
616 changes are held in a local @q{branch}, of which there may be
617 several, but these instructions assume you are using just one. The
618 files visible in the local repository always correspond to those
619 on the currently @q{checked out} local branch.
621 Files are edited on a local branch, and in that state the
622 changes are said to be @q{unstaged}. When editing is complete, the
623 changes are moved to being @q{staged for commit}, and finally the
624 changes are @q{committed} to the local branch. Once
625 committed, the changes are given a unique reference number called the
626 @q{Committish} which identifies them to Git. Such committed changes
627 can be sent to the master repository by @q{pushing} them (if you
628 have write permission) or by sending them by email to someone who
629 has, either complete or as a @q{diff} or @q{patch} (which send
630 just the differences from master).
632 @subsection Installing git
635 @uref{http://code.google.com/p/msysgit/downloads/list}
636 (note, not msysGit, which is for Git developers and not PortableGit,
637 which is not a full git installation) and
640 Note that most users will not need to install SSH. That is not
641 required until you have been granted direct push permissions to
642 the master git repository.
644 Start Git by clicking on the desktop icon.
645 This will bring up a command line bash shell. This may be
646 unfamiliar to Windows users. If so, follow these
647 instructions carefully. Commands are entered at a $ prompt
648 and are terminated by keying a newline.
650 @subsection Initialising Git
652 Decide where you wish to place your local Git repository,
653 creating the folders in Windows as necessary. Here we
654 call the folder to contain the repository [path]/Git.
655 You will need to have space for around 150Mbytes.
657 Start the Git bash shell by clicking on the desk-top icon installed
664 to position the shell at your new Git repository.
666 Note: if [path] contains folders with names containing
679 to initialize your Git repository.
681 Then type (all on one line; the shell will wrap automatically)
684 git remote add -f -t master origin git://git.sv.gnu.org/lilypond.git
687 to download the lilypond master files.
689 @warning{Be patient! Even on a broadband connection this can take
690 10 minutes or more. Wait for lots of [new tag] messages
693 We now need to generate a local copy of the downloaded files
694 in a new local branch. Your local branch needs to have a
695 name, here we call it @q{lily-local} - you may wish to make up
701 git checkout -b lily-local origin/master
704 to create the lily-local branch containing the local copies of the
705 master files. You will be advised your local branch has been set
706 up to track the remote branch.
708 Return to Windows Explorer and look in your Git repository. You
709 should see lots of folders. For example, the LilyPond documentation
710 can be found in Git/Documentation/user.
712 Terminate the Git bash shell by typing @code{exit}.
716 Almost all subsequent work will use the Git Graphical User
717 Interface, which avoids having to type command line
718 commands. To start Git GUI first start the Git bash shell by
719 clicking on the desktop icon, and type
726 The Git GUI will open in a new window. It contains four panels
727 and 7 pull-down menus. At this stage do not use any of the
728 commands under Branch, Commit, Merge or Remote. These will
731 The two panels on the left contain the names of files which
732 you are in the process of editing (Unstaged Changes), and
733 files you have finished editing and have staged ready for
734 committing (Staged Changes). At this stage these panels will
735 be empty as you have not yet made any changes to any file.
736 After a file has been edited and saved the top panel on the right
737 will display the differences between the edited file selected
738 in one of the panels on the left and the last version committed.
740 The final panel at bottom right is used to enter a descriptive
741 message about the change before committing it.
743 The Git GUI is terminated by entering CNTL-Q while it is the
744 active window or by clicking on the usual Windows close-window
747 @subsection Personalising your local git repository
749 Open the Git GUI, click on
755 and enter your name and email address in the
756 left-hand (Git Repository) panel. Leave everything
757 else unchanged and save it.
759 Note that Windows users must leave the default setting for line
760 endings unchanged. All files in a git repository must have lines
761 terminated by just a LF, as this is required for Merge to work, but
762 Windows files are terminated by CRLF by default. The git default
763 setting causes the line endings of files in a Windows git repository
764 to be flipped automatically between LF and CRLF as required. This
765 enables files to be edited by any Windows editor without causing
766 problems in the git repository.
768 @subsection Checking out a branch
770 At this stage you have two branches in your local repository,
771 both identical. To see them click on
777 You should have one local branch called @w{lily-local} and one
778 tracking branch called @w{origin/master}. The latter is your
779 local copy of the @w{remote/origin/master} branch in the master
780 LilyPond repository. The @w{lily-local} branch is where you
781 will make your local changes.
783 When a particular branch is selected, i.e., checked out, the
784 files visible in your repository are changed to reflect the
785 state of the files on that branch.
787 @subsection Updating files from @w{remote/origin/master}
789 Before starting the editing of a file, ensure your local branches
790 contain the latest version in @w{remote/origin/master} by first
794 Remote -> Fetch from -> origin
800 This will place the latest version of every file, including all the
801 changes made by others,
802 into the @q{origin/master} branch of the tracking branches
803 in your git repository. You can see these files by checking
804 out this branch. This will not affect any files you have
805 modified in your local branch.
807 You then need to merge these fetched files into your local
808 branch by clicking on
815 and if necessary select the local branch into which the merge
818 Note that a merge cannot be completed if there are any local
819 uncommitted changes on the lily-local branch.
821 This will update all the files in that branch to reflect the
822 current state of the @w{origin/master} branch. If any of the
823 changes conflict with changes you have made yourself recently
824 you will be notified of the conflict (see below).
826 @subsection Editing files
828 First ensure your lily-local branch is checked out, then
829 simply edit the files in your local Git repository with your
830 favourite editor and save them back there. If any file contains
831 non-ASCII characters ensure you save it in UTF-8 format. Git will
832 detect any changes whenever you restart Git GUI and the file names
833 will then be listed in the Unstaged Changes panel.
834 Or you can click the Rescan button to refresh the panel
835 contents at any time. You may break off and resume at
838 The changes you have made may be displayed in diff form
839 in the top right-hand panel by clicking on the name in
842 When your editing is complete, move the files from being
843 Unstaged to Staged by clicking the document symbol to
844 the left of each name. If you change your mind it can
845 be moved back by clicking on the ticked box to the
848 Finally the changes you have made may be committed to
849 your lily-local branch by entering a brief message in
850 the Commit Message box and clicking the Commit button.
852 If you wish to amend your changes after a commit has been
853 made, the original version and the changes you made in that
854 commit may be recovered by selecting
857 Commit -> Amend Last Commit
861 or by checking the Amend Last Commit radio button at bottom left.
862 This will return the changes to the Staged state, so further
863 editing made be carried out within that commit. This must only be
864 done @emph{before} the changes have been Pushed or sent to your
865 mentor for Pushing - after that it is too late and corrections
866 have to be made as a separate commit.
869 @subsection Sending changes to remote/origin/master
871 If you do not have write access to @w{remote/origin/master} you will
872 need to send your changes by email to someone who does.
874 First you need to create a diff or patch file containing
875 your changes. To create this, the file must first be
876 committed. Then terminate the Git GUI. In the
877 git bash shell first cd to your Git repository with
883 if necessary, then produce the patch with
886 git format-patch origin
889 This will create a patch file for all the locally committed files
890 which differ from @w{origin/master}. The patch file can be found
891 in [path]/Git and will have a name formed from n and the commit
894 @subsection Resolving merge conflicts
896 As soon as you have committed a changed file your local
897 branch has diverged from @w{origin/master}, and will
898 remain diverged until your changes have been committed
899 in @w{remote/origin/master} and Fetched back into your
900 @w{origin/master}. Similarly, if a new commit has been made
901 to @w{remote/origin/master} by someone else and Fetched, your
902 lily-local branch is divergent. You can detect a divergent
903 branch by clicking on
906 Repository -> Visualise all branch history
909 This opens up a very useful new window called @q{gitk}.
910 Use this to browse all the commits made by others.
912 If the diagram at top left of the resulting window
913 does not show your branch's tag on the same node as
914 the @w{remote/origins/master} tag your branch has diverged from
915 @w{origin/master}. This is quite normal if files you have modified
916 yourself have not yet been Pushed to @w{remote/origin/master} and
917 Fetched, or if files modified and committed by others have been
918 Fetched since you last Merged @w{origin/master} into your lily-local
921 If a file being merged from @w{origin/master} differs from
922 one you have modified in a way that cannot be resolved
923 automatically by git, Merge will report a Conflict
924 which you must resolve by editing the file to create the
925 version you wish to keep.
927 This could happen if the person updating @w{remote/origin/master}
928 for you has added some changes of his own before
929 committing your changes to @w{remote/origin/master}, or if someone
930 else has changed the same file since you last
931 fetched the file from @w{remote/origin/master}.
933 Open the file in your editor and look for sections which
934 are delimited with ...
936 [to be completed when I next have a merge conflict to be
937 sure I give the right instructions -td]
940 @subsection Other actions
942 The instructions above describe the simplest way of using
943 git on Windows. Other git facilities which may usefully
944 supplement these include
948 @item Using multiple local branches (Create, Rename, Delete)
949 @item Resetting branches
950 @item Cherry-picking commits
951 @item Pushing commits to @w{remote/origin/master}
952 @item Using gitk to review history
956 Once familiarity with using git on Windows has been gained the
957 standard git manuals can be used to learn about these.
960 @node Development inside VirtualBox (compiling on Windows)
961 @section Development inside VirtualBox (compiling on Windows)