Git Usage

Git windows guide
The guide for Windows users is located here: Git Usage Windows

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

If you are a developer, clone the repository.

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:

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: if not set:

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:

Linux and OSX users should set autocrlf to 'input'

Updating
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

A safe bet is to set this to be done automatically.

Pushing
Please use  to look at the log before pushing. If there are merge commits that you don't understand, please ask for help before pushing.

'''Never EVER force a push (non-fast-forward commit) to mainline. Ever. Doing so will result in your push privileges being revoked.

Merging
Always use the --log option to add a description of what commits are being merged. You can (and should) set this as a default:

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: You then just rinse/repeat until all issues are ironed out. feature_rebase is then what is pulled into master nice and cleanly.