1 \chapter{Bacula Git Usage}
2 \label{_GitChapterStart}
5 \addcontentsline{toc}{section}{Bacula Bit Usage}
7 This chapter is intended to help you use the Git source code
8 repositories to obtain, modify, and submit Bacula source code.
11 \section{Bacula Git repositories}
13 \addcontentsline{toc}{subsection}{Git repositories}
14 As of September 2009, the Bacula source code has been split into
15 three Git repositories. One is a repository that holds the
16 main Bacula source code with directories {\bf bacula}, {\bf gui},
17 and {\bf regress}. The second repository contains
18 the directories {\bf docs} directory, and the third repository
19 contains the {\bf rescue} directory. All three repositories are
22 Previously everything was in a single SVN repository.
23 We have split the SVN repository into three because Git
24 offers significant advantages for ease of managing and integrating
25 developer's changes. However, one of the disadvantages of Git is that you
26 must work with the full repository, while SVN allows you to checkout
27 individual directories. If we put everything into a single Git
28 repository it would be far bigger than most developers would want
29 to checkout, so we have separted the docs and rescue into their own
30 repositories, and moved only the parts that are most actively
31 worked on by the developers (bacula, gui, and regress) to a the
32 Git Bacula repository.
34 Bacula developers must now have a certain knowledege of Git.
38 \addcontentsline{toc}{subsection}{Git Usage}
40 Please note that if you are familiar with SVN, Git is similar,
41 (and better), but there can be a few surprising differences that
42 can be very confusing (nothing worse than converting from CVS to SVN).
44 The main Bacula Git repo contains the subdirectories {\bf bacula}, {\bf gui},
45 and {\bf regress}. With Git it is not possible to pull only a
46 single directory, because of the hash code nature of Git, you
47 must take all or nothing.
49 For developers, the most important thing to remember about Git and
50 the Source Forge repository is not to "force" a {\bf push} to the
51 repository. Doing so, can possibly rewrite
52 the Git repository history and cause a lot of problems for the
55 You can get a full copy of the Source Forge Bacula Git repository with the
59 git clone http://git.bacula.org/bacula trunk
62 This will put a read-only copy into the directory {\bf trunk}
63 in your current directory, and {\bf trunk} will contain
64 the subdirectories: {\bf bacula}, {\bf gui}, and {\bf regress}.
65 Obviously you can use any name an not just {\bf trunk}. In fact,
66 once you have the repository in say {\bf trunk}, you can copy the
67 whole directory to another place and have a fully functional
70 The above command needs to be done only once. Thereafter, you can:
74 git pull # refresh my repo with the latest code
77 As of August 2009, the size of the repository ({\bf trunk} in the above
78 example) will be approximately 55 Megabytes. However, if you build
79 from source in this directory and do a lot of updates and regression
80 testing, the directory could become several hundred megabytes.
82 \subsection{Learning Git}
84 If you want to learn more about Git, we recommend that you visit:\\
85 \elink{http://book.git-scm.com/}{http://book.git-scm.com/}.
87 Some of the differences between Git and SVN are:
89 \item Your main Git directory is a full Git repository to which you can
90 and must commit. In fact, we suggest you commit frequently.
91 \item When you commit, the commit goes into your local Git
92 database. You must use another command to write it to the
93 master Source Forge repository (see below).
94 \item The local Git database is kept in the directory {\bf .git} at the
95 top level of the directory.
96 \item All the important Git configuration information is kept in the
97 file {\bf .git/config} in ASCII format that is easy to manually edit.
98 \item When you do a {\bf commit} the changes are put in {\bf .git}
99 rather but not in the main Source Forge repository.
100 \item You can push your changes to the external repository using
101 the command {\bf git push} providing you have write permission
103 \item We restrict developers just learning git to have read-only
104 access until they feel comfortable with git before giving them
106 \item You can download all the current changes in the external repository
107 and merge them into your {\bf master} branch using the command
109 \item The command {\bf git add} is used to add a new file to the
110 repository AND to tell Git that you want a file that has changed
111 to be in the next commit. This has lots of advantages, because
112 a {\bf git commit} only commits those files that have been
113 explicitly added. Note with SVN {\bf add} is used only
114 to add new files to the repo.
115 \item You can add and commit all files modifed in one command
116 using {\bf git commit -a}.
117 \item This extra use of {\bf add} allows you to make a number
118 of changes then add only a few of the files and commit them,
119 then add more files and commit them until you have committed
120 everything. This has the advantage of allowing you to more
121 easily group small changes and do individaual commits on them.
122 By keeping commits smaller, and separated into topics, it makes
123 it much easier to later select certain commits for backporting.
124 \item If you {\bf git pull} from the main repository and make
125 some changes, and before you do a {\bf git push} someone
126 else pushes changes to the Git repository, your changes will
127 apply to an older version of the repository you will probably
128 get an error message such as:
132 To git@github.com:bacula/bacula.git
133 ! [rejected] master -> master (non-fast forward)
134 error: failed to push some refs to 'git@github.com:bacula/bacula.git'
137 which is Git's way of telling you that the main repository has changed
138 and that if you push your changes, they will not be integrated properly.
139 This is very similar to what happens when you do an "svn update" and
141 As we have noted above, you should never ask Git to force the push.
142 See below for an explanation of why.
143 \item To integrate (merge) your changes properly, you should always do
144 a {\bf git pull} just prior to doing a {\bf git push}.
145 \item If Git is unable to merge your changes or finds a conflict it
146 will tell you and you must do conflict resolution, which is much
147 easier in Git than in SVN.
148 \item Resolving conflicts is described below in the {\bf github} section.
151 \section{Step by Step Modifying Bacula Code}
152 Suppose you want to download Bacula source code, build it, make
153 a change, then submit your change to the Bacula developers. What
157 \item Tell git who you are:\\
159 git config --global user.name "First-name Last-name"
160 git config --global user.email "email@address.com"
163 Where you put your real name and your email address. Since
164 this is global, you only need to do it once on any given
165 machine regardless of how many git repos you work with.
167 \item Download the Source code:\\
169 git clone http://git.bacula.org/bacula trunk
172 \item Configure and Build Bacula:\\
174 ./configure (all-your-normal-options)
178 \item Create a branch to work on:
181 git checkout -b bugfix master
184 \item Edit, build, Test, ...\\
191 Note: if you forget to create a working branch prior to making
192 changes, and you make them on master, this is no problem providing
193 that you create the working branch before your first commit.
194 So assuming that you have edited master instead of your bugfix
195 branch, you can simply:
198 git checkout -b bugfix master
201 and a new bugfix branch will be created and checked out.
202 You can then proceed to committing to your bugfix branch as
203 described in the next step.
205 \item commit your work:
207 git commit -am "Short comment on what I did"
210 \item Possibly repeat the above two items
212 \item Switch back to the master branch:\\
217 \item Pull the latest changes:\\
222 \item Get back on your bugfix branch:\\
227 \item Merge your changes and correct any conflicts:\\
229 git rebase master bugfix
232 \item Fix any conflicts:\\
233 You will be notified if there are conflicts. The first
240 This will produce a diff of only the files having a conflict.
241 Fix each file in turn. When it is fixed, the diff for that file
244 For each file fixed, you must do the same as SVN, inform git with:
247 git add (name-of-file-no-longer-in-conflict)
250 \item When all files are fixed do:
252 git rebase --continue
255 \item If you find that it is impossible to reconcile the two
256 branches or you made a mistake in correcting and adding files,
257 before you enter the:
259 git rebase --continue
261 you can instead enter:
267 which will essentially cancel the the original git rebase and reset
268 everything to the beginning with no changes to your bugfix branch.
270 \item When you have completed the rebase and
271 are ready to send a patch, do the following:\\
274 git format-patch -M master
276 Look at the files produced. They should be numbered 0001-xxx.patch
277 where there is one file for each commit you did, number sequentially,
278 and the xxx is what you put in the commit comment.
280 \item If the patch files are good, send them by email to the developers
283 \item Then you can continue working on your code if you want, or
284 start another branch with a new project.
286 \item If you continue working on your bugfix branch, you should
287 do a {\bf git rebase master} from time to time, and when
288 your changes are committed to the repo, you will be automatically
289 synchronized. So that the next {\bf git format-patch} will produce
290 only the changes you made since the last format-patch you sent
298 \subsection{More Details}
300 Normally, you will work by creating a branch of the master branch of your
301 repository, make your modifications, then make sure it is up to date, and finally
302 create format-patch patches or push it to the Source Forge repo. Assuming
303 you call the Bacula repository {\bf trunk}, you might use the following
310 git checkout -b newbranch master
312 git add <file-edited>
313 git commit -m "<comment about commit>"
317 When you have completed working on your branch, you will do:
321 git checkout newbranch # ensure I am on my branch
322 git pull # get latest source code
323 git rebase master # merge my code
326 If you have completed your edits before anyone has modified the repository,
327 the {\bf git rebase master} will report that there was nothing to do. Otherwise,
328 it will merge the changes that were made in the repository before your changes.
329 If there are any conflicts, Git will tell you. Typically resolving conflicts with
330 Git is relatively easy. You simply make a diff:
336 Then edit each file that was listed in the {\bf git diff} to remove the
337 conflict, which will be indicated by lines of:
347 where {\bf text} is what is in the Bacula repository, and {\bf other text}
348 is what you have changed.
350 Once you have eliminated the conflict, the {\bf git diff} will show nothing,
354 git add <file-with-conflicts-fixed>
357 Once you have fixed all the files with conflicts in the above manner, you enter:
360 git rebase --continue
363 and your rebase will be complete.
365 If for some reason, before doing the --continue, you want to abort the rebase and return to what you had, you enter:
371 Finally to make a set of patch files
374 git format-patch -M master
377 When you see your changes have been integrated and pushed to the
378 main repo, you can delete your branch with:
382 git branch -D newbranch
386 \section{Forcing Changes}
387 If you want to understand why it is not a good idea to force a
388 push to the repository, look at the following picture:
390 \bsysimageH{git-edit-commit}{Git Edit Commit}{}
392 The above graphic has three lines of circles. Each circle represents
393 a commit, and time runs from the left to the right. The top line
394 shows the repository just before you are going to do a push. Note the
395 point at which you pulled is the circle on the left, your changes are
396 represented by the circle labeled {\bf Your mods}. It is shown below
397 to indicate that the changes are only in your local repository. Finally,
398 there are pushes A and B that came after the time at which you pulled.
400 If you were to force your changes into the repository, Git would place them
401 immediately after the point at which you pulled them, so they would
402 go before the pushes A and B. However, doing so would rewrite the history
403 of the repository and make it very difficult for other users to synchronize
404 since they would have to somehow wedge their changes at some point before the
405 current HEAD of the repository. This situation is shown by the second line of
408 What you really want to do is to put your changes after Push B (the current HEAD).
409 This is shown in the third line of pushes. The best way to accomplish this is to
410 work in a branch, pull the repository so you have your master equal to HEAD (in first
411 line), then to rebase your branch on the current master and then commit it. The
412 exact commands to accomplish this are shown in the next couple of sections.