1 Git windows guide
The guide for Windows users is located here: Git Usage Windows
2 Clone the XBMC main repository
XBMC now uses git as its Software Configuration Management (SCM) framework. The main repository is located at github
For read only access
$ git clone git://github.com/xbmc/xbmc.git
If you are a developer, clone the repository.
$ git clone email@example.com:xbmc/xbmc.git
3 Fetch old branches and extra history
The following is ONLY useful for developers who wish to see extended XBMC history. Everyone else should stop here. Run this command from your tree. It requires git 1.6.5 or higher:
$ git fetch origin refs/old/heads/*:refs/remotes/svn-migration/* refs/replace/*:refs/replace/*
4 Platform Settings
4.1 Case Insensitive File Systems
Git wants to run under a case sensitive file system but under OSX and Windows, the file system might be case insensitive. Make sure that core.ignorecase is properly set. Check with:
$ git config --list
if not set:
$ git config --global core.ignorecase true
4.2 Line Endings
Windows users MUST use the git autocrlf feature. This is set by default by tortoise. If it's not set, you can do so manually:
$ git config --system core.autocrlf true
Linux and OSX users should set autocrlf to 'input'
$ git config --global core.autocrlf input
When updating from the main git repository (by default git will call this 'origin'), you should always rebase on top of your history, unless you know what you're doing.Always use
git pull --rebase
A safe bet is to set this to be done automatically.
$ git config branch.master.rebase true
6 PushingPlease use
Never EVER force a push (non-fast-forward commit) to mainline. Ever. Doing so will result in your push privileges being revoked.
Always use the --log option to add a description of what commits are being merged. You can (and should) set this as a default:
$ git config merge.log true
8.1 Maintaining a rebased version of a merge branch
A long-lived feature branch involving a bunch of developers at some point needs merging to mainline. During the review stage, this typically involves someone taking the time to rebase the feature branch on mainline so that the changes are easier to review for others, with a pull request being made. Review will inevitably result in fix commits being required, and where many developers are involved this can be messy if constantly rebased (as devs are working against a moving target). An alternative is to have 2 branches: The first rebased branch changes to the development branch with fixup commits being applied. A second branch is then created which is identical to the first, just rebased down. In order to maintain this arrangement, you need to be able to apply the top N commits from the development branch onto the rebased branch to ensure it's kept up to date. This can be done as follows:
$ git checkout feature_branch $ git checkout -b feature_rebase $ # ... do rebase ... $ git diff feature_branch # ensure your rebase hasn't dropped something. $ git checkout feature_branch $ git tag -f feature_last_rebase # so you know when you last rebased. $ # ... more commits on top of feature_branch ... $ git checkout feature_rebase $ git checkout -b tmp # create a temporary branch $ git branch -f feature_rebase feature_branch # move feature_rebase to the HEAD of feature_branch $ git rebase --onto tmp feature_last_rebase feature_rebase # rebase changes from the last rebase on top of feature_branch $ git diff feature_branch # ensure your rebased branch contains all the commits you want $ git branch -d tmp $ # ... do rebase ...
You then just rinse/repeat until all issues are ironed out. feature_rebase is then what is pulled into master nice and cleanly.