This chapter is intended to help you use the Git source code repositories to obtain, modify, and submit Bacula source code.
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.
Each major version of Bacula uses a specific branch name rather than the default git “master” branch. For example, the version 11.0.1 code will be accessible via the branch Branch-11.0. In this section, the word “master” refers to the current active development branch.
Bacula developers must now have a certain knowledege of Git.
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 git checkout -b Branch-11.0 origin/Branch-11.0
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.
Some of the differences between Git and SVN are:
git push To firstname.lastname@example.org:bacula/bacula.git ! [rejected] Branch-11.0 -> Branch-11.0 (non-fast forward) error: failed to push some refs to 'email@example.com:bacula/bacula.git'
which is Git's way of telling you that the main repository has changed and that if you push your changes, they will not be integrated properly. This is very similar to what happens when you do an "svn update" and get merge conflicts. As we have noted above, you should never ask Git to force the push. See below for an explanation of why.
git config --global user.name "First-name Last-name" git config --global user.email "firstname.lastname@example.org"
Where you put your real name and your email address. Since this is global, you only need to do it once on any given machine regardless of how many git repos you work with.
git clone http://git.bacula.org/bacula.git bacula
./configure (all-your-normal-options) make
cd bacula/bacula git checkout -b bugfix Branch-11.0
edit file jcr.h make test
Note: if you forget to create a working branch prior to making changes, and you make them on the development branch, this is no problem providing that you create the working branch before your first commit. So assuming that you have edited “master” instead of your bugfix branch, you can simply:
git checkout -b bugfix master
and a new bugfix branch will be created and checked out. You can then proceed to committing to your bugfix branch as described in the next step.
git commit -am "Short comment on what I did"
git checkout master
git checkout bugfix
git rebase master bugfix
This will produce a diff of only the files having a conflict. Fix each file in turn. When it is fixed, the diff for that file will go away.
For each file fixed, you must do the same as SVN, inform git with:
git add (name-of-file-no-longer-in-conflict)
git rebase --continue
git rebase --continueyou can instead enter:
git rebase --abort
which will essentially cancel the the original git rebase and reset everything to the beginning with no changes to your bugfix branch.
git checkout bugfix git format-patch -M masterLook at the files produced. They should be numbered 0001-xxx.patch where there is one file for each commit you did, number sequentially, and the xxx is what you put in the commit comment.
Normally, you will work by creating a branch of the development 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:
Then edit each file that was listed in the git diff to remove the conflict, which will be indicated by lines of:
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
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.