Subsections


Bacula Git Usage

This chapter is intended to help you use the Git source code repositories to obtain, modify, and submit Bacula source code.


Bacula Git repositories

As of September 2009, the Bacula source code has been split into three Git repositories. One is a repository that holds the main Bacula source code with directories bacula, gui, and regress. The second repository contains the directories docs directory, and the third repository contains the rescue directory. All three repositories are hosted by UKFast.

Previously everything was in a single SVN repository. We have split the SVN repository into three because Git offers significant advantages for ease of managing and integrating developer's changes. However, one of the disadvantages of Git is that you must work with the full repository, while SVN allows you to checkout individual directories. If we put everything into a single Git repository it would be far bigger than most developers would want to checkout, so we have separted the docs and rescue into their own repositories, and moved only the parts that are most actively worked on by the developers (bacula, gui, and regress) to a the Git Bacula repository.

Bacula developers must now have a certain knowledege of Git.


Git Usage

Please note that if you are familiar with SVN, Git is similar, (and better), but there can be a few surprising differences that can be very confusing (nothing worse than converting from CVS to SVN).

The main Bacula Git repo contains the subdirectories bacula, gui, and regress. With Git it is not possible to pull only a single directory, because of the hash code nature of Git, you must take all or nothing.

For developers, the most important thing to remember about Git and the bacula.org repository is not to "force" a push to the repository. Doing so, can possibly rewrite the Git repository history and cause a lot of problems for the project.

You can get a full copy of the Bacula Git repository with the following command:

git clone http://git.bacula.org/bacula.git bacula

This will put a read-only copy into the directory bacula in your current directory, and bacula will contain the subdirectories: bacula, gui, and regress. Obviously you can use any name an not just bacula. In fact, once you have the repository in say bacula, you can copy the whole directory to another place and have a fully functional git repository.

The above command needs to be done only once. Thereafter, you can:

cd bacula
git pull     # refresh my repo with the latest code

As of August 2009, the size of the repository (bacula in the above example) will be approximately 55 Megabytes. However, if you build from source in this directory and do a lot of updates and regression testing, the directory could become several hundred megabytes.


Learning Git

If you want to learn more about Git, we recommend that you visit:
http://book.git-scm.com/http://book.git-scm.com/.

Some of the differences between Git and SVN are:

Step by Step Modifying Bacula Code

Suppose you want to download Bacula source code, build it, make a change, then submit your change to the Bacula developers. What would you do?

More Details

Normally, you will work by creating a branch of the master branch of your repository, make your modifications, then make sure it is up to date, and finally create format-patch patches or push it to the bacula.org. Assuming you call the Bacula repository bacula, you might use the following commands:

cd bacula
git checkout bacula
git pull 
git checkout -b newbranch bacula
(edit, ...)
git add <file-edited>
git commit -m "<comment about commit>"
...

When you have completed working on your branch, you will do:

cd bacula
git checkout newbranch  # ensure I am on my branch
git pull                # get latest source code
git rebase master       # merge my code

If you have completed your edits before anyone has modified the repository, the git rebase master will report that there was nothing to do. Otherwise, it will merge the changes that were made in the repository before your changes. If there are any conflicts, Git will tell you. Typically resolving conflicts with Git is relatively easy. You simply make a diff:

git diff

Then edit each file that was listed in the git diff to remove the conflict, which will be indicated by lines of:

<<<<<<< HEAD
text
>>>>>>>>
other text
=====

where text is what is in the Bacula repository, and other text is what you have changed.

Once you have eliminated the conflict, the git diff will show nothing, and you must do a:

git add <file-with-conflicts-fixed>

Once you have fixed all the files with conflicts in the above manner, you enter:

git rebase --continue

and your rebase will be complete.

If for some reason, before doing the -continue, you want to abort the rebase and return to what you had, you enter:

git rebase --abort

Finally to make a set of patch files

git format-patch -M master

When you see your changes have been integrated and pushed to the main repo, you can delete your branch with:

git checkout master
git branch -D newbranch

Forcing Changes

If you want to understand why it is not a good idea to force a push to the repository, look at the following picture:

Image git-edit-commit
The above graphic has three lines of circles. Each circle represents a commit, and time runs from the left to the right. The top line shows the repository just before you are going to do a push. Note the point at which you pulled is the circle on the left, your changes are represented by the circle labeled Your mods. It is shown below to indicate that the changes are only in your local repository. Finally, there are pushes A and B that came after the time at which you pulled.

If you were to force your changes into the repository, Git would place them immediately after the point at which you pulled them, so they would go before the pushes A and B. However, doing so would rewrite the history of the repository and make it very difficult for other users to synchronize since they would have to somehow wedge their changes at some point before the current HEAD of the repository. This situation is shown by the second line of pushes.

What you really want to do is to put your changes after Push B (the current HEAD). This is shown in the third line of pushes. The best way to accomplish this is to work in a branch, pull the repository so you have your master equal to HEAD (in first line), then to rebase your branch on the current master and then commit it. The exact commands to accomplish this are shown in the next couple of sections.