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 Download the Source code:\\
159 git clone http://git.bacula.org/bacula trunk
162 \item Configure and Build Bacula:\\
164 ./configure (all-your-normal-options)
168 \item Create a branch to work on:
171 git checkout -b bugfix master
174 \item Edit, build, Test, ...\\
181 \item commit your work:
183 git commit -am "Short comment on what I did"
186 \item Possibly repeat the above two items
188 \item Switch back to the master branch:\\
193 \item Pull the latest changes:\\
198 \item Get back on your bugfix branch:\\
203 \item Merge your changes and correct any conflicts:\\
205 git rebase master bugfix
208 \item Fix any conflicts:\\
209 You will be notified if there are conflicts. The first
216 This will produce a diff of only the files having a conflict.
217 Fix each file in turn. When it is fixed, the diff for that file
220 For each file fixed, you must do the same as SVN, inform git with:
223 git add (name-of-file-no-longer-in-conflict)
226 \item When all files are fixed do:
228 git rebase --continue
231 \item When you are ready to send a patch, do the following:\\
234 git format-patch -M master
236 Look at the files produced. They should be numbered 0001-xxx.patch
237 where there is one file for each commit you did, number sequentially,
238 and the xxx is what you put in the commit comment.
240 \item If the patch files are good, send them by email to the developers
247 \subsection{More Details}
249 Normally, you will work by creating a branch of the master branch of your
250 repository, make your modifications, then make sure it is up to date, and finally
251 create format-patch patches or push it to the Source Forge repo. Assuming
252 you call the Bacula repository {\bf trunk}, you might use the following
259 git checkout -b newbranch master
261 git add <file-edited>
262 git commit -m "<comment about commit>"
266 When you have completed working on your branch, you will do:
270 git checkout newbranch # ensure I am on my branch
271 git pull # get latest source code
272 git rebase master # merge my code
275 If you have completed your edits before anyone has modified the repository,
276 the {\bf git rebase master} will report that there was nothing to do. Otherwise,
277 it will merge the changes that were made in the repository before your changes.
278 If there are any conflicts, Git will tell you. Typically resolving conflicts with
279 Git is relatively easy. You simply make a diff:
285 Then edit each file that was listed in the {\bf git diff} to remove the
286 conflict, which will be indicated by lines of:
296 where {\bf text} is what is in the Bacula repository, and {\bf other text}
297 is what you have changed.
299 Once you have eliminated the conflict, the {\bf git diff} will show nothing,
303 git add <file-with-conflicts-fixed>
306 Once you have fixed all the files with conflicts in the above manner, you enter:
309 git rebase --continue
312 and your rebase will be complete.
314 If for some reason, before doing the --continue, you want to abort the rebase and return to what you had, you enter:
320 Finally to make a set of patch files
323 git format-patch -M master
326 When you see your changes have been integrated and pushed to the
327 main repo, you can delete your branch with:
331 git branch -D newbranch
335 \section{Forcing Changes}
336 If you want to understand why it is not a good idea to force a
337 push to the repository, look at the following picture:
339 \includegraphics[width=0.85\textwidth]{\idir git-edit-commit.eps}
341 The above graphic has three lines of circles. Each circle represents
342 a commit, and time runs from the left to the right. The top line
343 shows the repository just before you are going to do a push. Note the
344 point at which you pulled is the circle on the left, your changes are
345 represented by the circle labeled {\bf Your mods}. It is shown below
346 to indicate that the changes are only in your local repository. Finally,
347 there are pushes A and B that came after the time at which you pulled.
349 If you were to force your changes into the repository, Git would place them
350 immediately after the point at which you pulled them, so they would
351 go before the pushes A and B. However, doing so would rewrite the history
352 of the repository and make it very difficult for other users to synchronize
353 since they would have to somehow wedge their changes at some point before the
354 current HEAD of the repository. This situation is shown by the second line of
357 What you really want to do is to put your changes after Push B (the current HEAD).
358 This is shown in the third line of pushes. The best way to accomplish this is to
359 work in a branch, pull the repository so you have your master equal to HEAD (in first
360 line), then to rebase your branch on the current master and then commit it. The
361 exact commands to accomplish this are shown in the next couple of sections.