Revision as of 18:12, 7 November 2007

Quick Instructions

To get up and running, you just need one command. This will create a directory called openbox and download the git repository into it:

git clone git://git.icculus.org/mikachu/openbox openbox

To get the latest changes, from inside the downloaded git repository, run

git pull

Branches

Currently, there are three branches of interest in the Openbox git repos: master, 3.4-working and backport. Master is the branch that will most likely become Openbox 3.5 or so, 3.4-working keeps compatibility with the rc.xml file fron the 3.4.x releases, and backport is where we put fixes and features that should go in both the other branches.

By default you will get the master branch, hence the name. If you want the 3.4-working branch, run

git checkout --track -b 3.4-working origin/3.4-working

You can now switch between them with git checkout master and git checkout 3.4-working.

If you want the very latest changes, first decide if you want 3.4-working or master, then check if we've recently merged the backport branch, for example by checking the output of git-log, looking at gitk --all or at the gitweb interface (look near the bottom under the "heads" header). If there are any interesting changes in the backport branch you want, just run

git merge origin/backport

and git will pull in the changes for you. Note however that a git pull will not remerge backport for you, it will only get updates from the branch you're currently on. If there are new commits on backport just rerun the merge command.

Local changes

Unlike CVS and Subversion, git lets you have local changes while still tracking upstream development, in a nut shell, make your changes and run

git commit -a -m "informative message".

It's usually a good idea to keep your changes in a separate branch. You can do this in a couple of ways, the easiest way is to run

git checkout -b my-branch master

then commit all your changes to that branch.

Conflicting changes

If you hang on to your changes for a long time, it's likely that we will make commits that conflict with yours. There are two ways to deal with this, you can either git-merge our branch and resolve the differences, but the better way is to use git-rebase. This command will take your commits and apply them to the tip (ie latest version) of the specified branch, pausing after each commit that conflicts. This usually makes it easier to resolve the conflicts and also gives a nicer history. Using git-rebase is a bit complicated so read the man page.

If you just want to test that your changes work with the latest version of openbox, you can merge master and then later use git reset --hard HEAD^ to revert the merge. However, I recommend first doing a git checkout -b my-temp, since running git reset twice will continue reverting real commits, so it's easy to mess up. If you're doing all the temp merging on a separate branch you don't have to worry about that.

Contributing code

You've coded an exciting feature and now you want to send a diff, how to do it? git-diff you might guess, and while that will produce a diff you can send, git-format-patch is a bit nicer as it will automatically give you a patch file per commit that you want to send, with the commit message in each file.

Another option is to set up your own public repo and simply tell us where to pull your changes from, look at the git-daemon man page for details. You can also use the git-bundle command to send a file that contains all commits, which we can then pull from. For example if you've made all your commits on the branch my-branch which you produced at some point from git checkout -b master, you can produce your bundle with

git bundle create my-bundle master..my-branch

then send the file my-bundle to us.

Low bandwidth option

If your internet connection is very slow (the full git repo is currently around 8.5MB) and you just want the very latest version without any history, you can run

git clone --depth 1 git://git.icculus.org/mikachu/openbox openbox

This will give you only the current and preceding commit from each branch, but you can't do much more with your repo than compile the code. Merging as described above will only work if you use a depth high enough to include the point where the backport branch separated from master. See the git-clone and git-fetch man pages for further details.

You can also download a tarball of any revision via gitweb. Click "tree" next to a branch name at the bottom, then "snapshot" at the top of the new page.

Alternate repos

Due to the distributed nature of git, you can choose to pull from various upstream locations (see the git-remote man page for details on how to use several remotes).

git://git.icculus.org/dana/openbox
git://git.icculus.org/mikachu/openbox
git://mikachu.ath.cx/openbox.git
git://repo.or.cz/openbox.git

The astute git user will notice that there are some variations in branches offered among these, for example dana has a libs branch that separates out some common wm code in a library, and mikachu has a mikabox branch which is just some crazy stuff.

Further reading

On the git homepage there are many great tutorials and all the man pages are available for browsing as well.