1 @c -*- coding: us-ascii; mode: texinfo; -*-
2 @node Starting with git
3 @chapter Starting with git
6 * Getting the source code::
7 * Updating the source code::
8 * Sharing your changes::
9 * Other interesting Git commands::
14 @node Getting the source code
15 @section Getting the source code
20 * Website source code::
21 * Documentation translations source code::
23 * Other locations for git::
24 * Git user configuration::
27 @node Git introduction
28 @subsection Git introduction
30 The source code is kept in a git respository. This allows us to
31 track changes to files, and for multiple people to work on the
32 same set of files (generally) without any problems.
34 @warning{These instructions assume that you are using the
35 command-line version of git 1.5 or higher. Windows users should
36 skip to @ref{Git on Windows}.}
39 @node Main source code
40 @subsection Main source code
42 To get the main source code and documentation,
47 mkdir lilypond; cd lilypond
49 git remote add -f -t master -m master origin git://git.sv.gnu.org/lilypond.git/
50 git checkout -b master origin/master
54 @node Website source code
55 @subsection Website source code
57 To get the website (including translations),
62 mkdir lilypod-web ; cd lilypond-web
64 git remote add -f -t web -m web origin git://git.sv.gnu.org/lilypond.git/
65 git checkout -b web origin/web
69 @node Documentation translations source code
70 @subsection Documentation translations source code
72 To translate the documentation (@emph{not} the website),
77 mkdir lilypond-translate; cd lilypond-translate
79 git remote add -f -t web -m web origin git://git.sv.gnu.org/lilypond.git/
80 git checkout -b web origin/web
85 @subsection Other branches
87 Most contributors will never need to touch the other branches. If
88 you wish to do so, you will need more familiarity with git.
93 This stores the Grand Unified Binary, our cross-platform building
94 tool. For more info, see @uref{http://lilypond.org/gub}. The git
98 http://github.com/janneke/gub
101 @item @code{dev/XYZ}:
102 These branches are for individual developers. They store code
103 which is not yet stable enough to be added to the @code{master}
106 @item @code{stable/XYZ}:
107 The branches are kept for archival reasons.
112 @node Other locations for git
113 @subsection Other locations for git
115 If you have difficulty connecting to most of the repositories
116 listed in earlier sections, try:
119 git://git.sv.gnu.org/lilypond.git
120 http://git.sv.gnu.org/r/lilypond.git
121 ssh://git.sv.gnu.org/srv/git/lilypond.git
125 @node Git user configuration
126 @subsection Git user configuration
128 To configure git to automatically use your name and email address
132 git config --global user.name "MYNAME"
133 git config --global user.email myemail@@example.net
137 @node Updating the source code
138 @section Updating the source code
141 * Importance of updating::
143 * Resolving conflicts::
148 @node Importance of updating
149 @subsection Importance of updating
151 In a large project like LilyPond, contributors sometimes edit the
152 same file at the same time. As long as everybody updates their
153 version of the file with the most recent changes (@qq{pull}ing),
154 there are generally no problems with this multiple-person editing.
155 However, serious problems can arise if you do not pull before
160 @subsection Updating command
162 Whenever you are asked to pull, it means you should update your
163 local copy of the repository with the changes made by others on
164 the remote @code{git.sv.gnu.org} repository:
171 @node Resolving conflicts
172 @subsection Resolving conflicts
174 Occasionally an update may result in conflicts -- this happens
175 when you and somebody else hae modified the same part of the same
176 file and git cannot figure out how to merge the two versions
177 together. When this happens, you must manually merge the two
185 @node Technical notes
186 @subsection Technical notes
188 TODO: I'm not going to bother with this section. -gp
190 Let's explain a bit of Git vocabulary. The @code{git pull origin}
191 command is just a shortcut for this command:
194 git pull git://git.sv.gnu.org/lilypond.git/ MY-BRANCH:origin/MY-BRANCH
197 A commit is a set of changes made to the sources; it also includes
198 the committish of the parent commit, the name and e-mail of the
199 author (the person who wrote the changes), the name and e-mail of
200 the committer (the person who brings these changes into the git
201 repository), and a commit message.
203 A committish is the SHA1 checksum of a commit, a number made of 40
204 hexadecimal digits, which acts as the internal unique identifier
205 for this commit. To refer to a particular revision, don't use
206 vague references like the (approximative) date, simply
207 copy'n'paste the committish.
209 A branch is a tree (in the mathematical or computer science sense)
210 of commits, and the topmost commit of this branch is called a
213 The "git fetch" command above has created a branch called
214 @code{origin/web} in your local Git repository. As this branch is
215 a copy of the remote branch web from git.sv.gnu.org LilyPond
216 repository, it is called a `remote branch', and is meant to track
217 the changes on the branch from git.sv.gnu.org: it will be updated
218 every time you run 'git pull' or 'git fetch' with this branch
219 reference as argument, e.g. by using .git/remotes/web remote file
220 when running 'git fetch web'.
222 The 'git checkout' command above has created a branch named 'web'. At
223 the beginning, this branch is identical to 'origin/web', but it will
224 differ as soon as you make changes, e.g. adding newly translated
225 pages. Whenever you pull, you merge the changes from origin/web and
226 your web branch since the last pulling. If you do not have push
227 (i.e. "write") access on git.sv.gnu.org, your web branch will always
228 differ from origin/web. In this case, remember that other people
229 working like you on the remote web branch of
230 git://git.sv.gnu.org/lilypond.git/ know nothing about your own web
231 branch: this means that whenever you use a committish or make a patch,
232 others expect you to take the lastest commit of origin/web branch as a
235 This README tries to explain most of Git commands needed for
236 translating the web site. However, you are invited to read
237 further documentation to make git more familiar to you; for
238 instance, take a look at @uref{http://git.or.cz/gitwiki/},
239 especially GitDocumentation and GitGlossary; a good alternative to
240 reading the wiki is reading the first two chapters of Git User's
242 @uref{http://www.kernel.org/pub/software/scm/git/docs/user-manual.html}
246 @node Sharing your changes
247 @section Sharing your changes
250 * Producing a patch::
251 * Committing directly::
255 @node Producing a patch
256 @subsection Producing a patch
258 Once you have finished editing your files, checked that your
259 changes meet the @ref{Code style} and/or @ref{Documentation
260 policy}, and checked that the entire thing compiles, you may
264 git-format-patch HEAD
267 Send an email to @email{lilypond-devel@@gnu.org} with the diff as
271 @node Committing directly
272 @subsection Committing directly
274 Most contributors do not have permission to commit directly. If
275 you do, edit @file{.git/config} to contain
278 FIXME? Is anything needed, or did the previous commands set it
282 You may then @code{git push}.
285 @node Other interesting Git commands
286 @section Other interesting Git commands
290 * Applying git patches::
297 The commands above don't only bring you the latest version of the
298 sources, but also the full history of revisions (revisons, also
299 called commits, are changes made to the sources), stored in the
300 .git directory. You can browse this history with
303 git log # only shows the logs (author, committish and commit message)
304 git log -p # also shows diffs
305 gitk # shows history graphically
309 @node Applying git patches
310 @subsection Applying git patches
312 Well-formed git patches should be committed with
318 Patches created without @code{git-format-patch} should be
328 @section Git on Windows
330 @c Some of this may duplicate stuff in other sections
331 @c Clear this up later -td
333 @subsection Background to nomenclature
335 Git is a system for tracking the changes made to source files by
336 a distributed set of editors. It is designed to work without a
337 master repository, but we have chosen to have a master respository
338 for LilyPond files. Editors hold local copies of the master
339 repository together with any changes they have made locally. Local
340 changes are held in a local @q{branch}, of which there may be
341 several. The files in the local repository always correspond to
342 those on the currently @q{checked out} local branch.
344 Files are edited on a local branch, and in that state the
345 changes are said to be @q{unstaged}. When editing is complete, the
346 changes are moved to being @q{staged for commit}, and finally the
347 changes are @q{committed} to the local branch. Once
348 committed, the changes are given a unique reference number called the
349 @q{Committish} which identifies them to Git. Such committed changes
350 can be sent to the master repository by @q{pushing} them (if you
351 have write permission) or by sending them by email to someone who
352 has, either complete or as a @q{diff} or @q{patch} (which send
353 just the differences from master).
355 @subsection Installing git
358 @uref{http://code.google.com/p/msysgit/downloads/list}.
359 (Note, not msysGit, which is for Git developers) and
360 install. Start Git by clicking on the desktop icon.
361 This will bring up a command line bash shell. This will be
362 unfamiliar to most Windows users, so follow these
363 instructions carefully. Commands are entered at a $ prompt
364 and are terminated by keying a newline.
366 @subsection Initialising Git
368 Decide where you wish to place your local Git repository,
369 creating the folders in Windows as necessary. Here we
370 call the folder to contain the repository [path]/Git.
371 You will need to have space for around 150Mbytes.
373 In the git bash shell type
379 to position the shell at your new Git repository.
381 Note: if [path] contains folders with names containing
394 to initialize your Git repository.
396 Then type (all on one line; the shell will wrap automatically)
399 git remote add -f -t master origin git://git.sv.gnu.org/lilypond.git
402 to download the lilypond master files.
404 @warning{Be patient! Even on a broadband connection this can take
405 10 minutes or more. Wait for lots of [new tag] messages
408 We now need to generate a local copy of the downloaded files
409 in a new local branch. Your local branch needs to have a
410 name, here we call it @q{lily-local} - make up your own.
414 git checkout -b lily-local origin/master
417 to create the lily-local branch containing the local copies of the
418 master files. You will be advised your local branch has been set
419 up to track the remote branch.
421 Return to Windows and look in your Git repository. You
422 should see lots of folders. The LilyPond documentation
423 can be found in Git/Documentation/user.
425 Terminate the Git bash shell with the exit command.
429 Almost all subsequent work will use the Git Graphical User
430 Interface, which avoids having to type command line
431 commands. To start Git GUI first start the Git bash shell by
432 clicking on the desktop icon, and type
439 The Git GUI will open in a new window. It contains four panels
440 and 7 pull-down menus. At this stage do not use any of the
441 commands under Branch, Commit, Merge or Remote. These will
444 The two panels on the left contain the names of files which
445 you are in the process of editing (Unstaged Changes),and
446 files you have finished editing and have staged ready for
447 committing (Staged Changes). At this stage these panels will
448 be empty as your local branch is the same as the master branch.
449 After a file has been edited and saved the top panel on the right
450 will display the differences between the edited file selected
451 from one of the left panels and the one on master. The
452 final panel at bottom right is used to enter a descriptive
453 message about the change before committing a file.
455 The Git GUI is terminated by entering CNTL-Q while it is the
456 active window or by clicking on the usual Windows close-window
459 @subsection Personalising your local git repository
461 Open the Git GUI, click on
467 and enter your name and email address in the
468 left-hand (Git Repository) panel. Leave everything
469 else unchanged and save it.
471 @subsection Checking out a branch
473 At this stage you have two branches in your local repository,
474 both identical. To see them click on
480 You should have one local branch called lily-local and one
481 tracking branch called origin/master.
483 When a particular branch is selected, i.e., checked out, the
484 files visible in your repository are changed to reflect the
485 changes made on that branch.
487 @subsection Updating files from master
489 Before starting the editing of a file ensure you have the
490 latest copy from master by first clicking
493 Remote -> Fetch from -> origin
498 This will place details of all the changes made by others
499 into the @q{origin/master} branch of the tracking branches
500 in your git repository. You can see these files by checking
501 out this branch. This will not affect any files
502 you have modified in any of your local branches.
504 To merge the changed files into your local branch click on
510 and if necessary select the local branch into which the merge
513 This will update all the files in that branch to reflect the
514 currect state of the origin/master branch. If any of the changes
515 conflict with changes you have made yourself recently
516 you will be notified of the conflict (see below).
518 @subsection Editing files
520 Simply edit the files in your local Git repository with
521 your favourite editor and save them back there. If any file contains
522 non-ASCII characters ensure you save it in UTF8 format. Git will
523 detect any changes whenever you restart Git GUI
524 and the file names will then be listed in the Unstaged Changes panel.
525 Or you can click the Rescan button to refresh the panel
526 contents at any time. You may break off and resume at
529 The changes you have made may be displayed in diff form
530 in the top right-hand panel by clicking on the name in
533 When your editing is complete, move the files from being
534 Unstaged to Staged by clicking the document symbol to
535 the left of each name. If you change your mind it can
536 be moved back by clicking on the ticked box to the
539 If you wish to cancel your changes the original version
540 may be recovered at any time before a commit is made
541 by selecting Commit -> Revert changes. This will even
542 recover a deleted file.
544 Finally the changes you have made may be committed to
545 your local branch by entering a brief message in
546 the Commit Message box and clicking the Commit button.
548 @subsection Sending changes to origin/master
550 If you do not have write access to master you will
551 need to send your changes by email to someone who does.
553 First you need to create a diff or patch file containing
554 your changes. To create this, the file must first be
555 committed. Then terminate the Git GUI. In the
556 git bash shell first cd to your Git repository with
562 if necessary, then produce the patch with
568 where n an integer, normally 1. This will create a
569 patch file for all the locally committed files which
570 differ from master. The patch file can be found in
571 [path]/Git and will have a name formed from n and the
574 @subsection Resolving merge conflicts
576 As soon as you have committed a changed file your
577 local branch has diverged from master, and will
578 remain diverged until your changes have been committed
579 in master. Similarly, if a new commit has been made
580 to master by someone else, your branch is divergent.
581 You can detect a divergent branch my clicking on
584 Repository -> Visualise all branch history
587 This opens up a very useful new window called @q{gitk}.
589 If the diagram at top left of the resulting window
590 does not show your branch on a single node at the
591 top your branch has diverged from master. This is
592 quite normal if files you have modified yourself
593 have not yet been committed to master, or if files
594 have been modified and committed by others since
597 If a file being merged from master differs from
598 one you have modified in a way that cannot be resolved
599 automatically by git, Merge will report a Conflict
600 which you must resolve by editing the file to create the
601 version you wish to keep.
603 This could happen if the person updating master
604 for you has added some changes of his own before
605 committing your changes to master, or if someone
606 else has updated the same parent file as you at
609 Open the file in your editor and look for sections which
612 [to be completed when I next have a merge conflict to be
613 sure I give the right instructions -td]