Getting the source code

Haiku's source code is currently being hosted in a Git based repository. Anonymous access will allow anyone to download Haiku's source code; However, only Haiku contributors with commit access should use the authenticated (non-anonymous) method.

Git Access - Anonymous testers

• Build Tools:

  git clone https://git.haiku-os.org/buildtools
  

  or (if you have a problem with https)

  git clone git://git.haiku-os.org/buildtools
  

• Haiku:

  git clone https://git.haiku-os.org/haiku
  

  or:

  git clone git://git.haiku-os.org/haiku
  

Git Access - Contributors with commit permission

• Configure Git on your system:

  Before making your first commit on a new system, be sure to configure Git. These global settings are stored in your git configuration directory (~/.git/) and will be appended to each commit as your personal information.

  git config –global user.name “John Doe”
  git config –global user.email “john.doe@developers.com”
  

  If you were used to the short version of the svn commands (st, di,… instead of status, diff,…), you’ll also want to set up similar shortcuts as aliases for the respective long git commands:

  git config –global alias.st “status -s”
  git config –global alias.di “diff”
  git config –global alias.ci “commit”
  git config –global alias.co “checkout”
  

  On Mac OS X, you should always set the following option in order to avoid confusion about the NFD and NFC representation of filenames:

  git config core.precomposeunicode true
  

• Build Tools:

  The <login>@ is only needed if your currently logged in username doesn’t match your git.haiku-os.org username.

  git clone ssh://<login>@git.haiku-os.org/buildtools
  

• Haiku:

  The <login>@ is only needed if your currently logged in username doesn’t match your git.haiku-os.org username.

  git clone ssh://<login>@git.haiku-os.org/haiku
  

Switching from anonymous to developer access

Just got commit access to Haiku? Congratulations! You don't need to checkout the sources again. Instead you can update your existing copy of the source to use the commiter access. Just change the remote URL:

git remote set-url origin ssh://<login>@git.haiku-os.org/haiku

Some Notes

• Case Sensitive Filesystem

  Haiku's source code needs to reside on a case sensitive file system.
  In short, such a file system recognizes "ThisIsAFile.txt" and "THISISAFILE.txt" as two different files. Some file systems that are (or could be) case in-sensitive include, FAT32, NTFS, and HFS+. Mac OS X's HFS+ is case in-sensitive by default. For more information regarding how to create a case-sensitive HFS+ volume, see this article.

• Getting the source code through an HTTP proxy

  Haiku's main Git repository does not allow HTTP access, which is a problem if you are accessing the Internet through a proxy server that only permits HTTP (port 80) traffic.
  Instead, use one of our mirror repositories at GitHub or Gitorious for anonymous HTTP access, they are both kept in sync with the main repository. First, set Git to connect through your proxy server:

  git config --global http.proxy http://proxyuser:proxypwd@proxy.server.com:8080
  

  Then clone the repositories from GitHub:

  git clone http://github.com/haiku/buildtools.git
  git clone http://github.com/haiku/haiku.git
  

  Alternatively, from Gitorious:

  git clone http://git.gitorious.org/haiku/buildtools.git
  git clone http://git.gitorious.org/haiku/haiku.git
  

  Note however that these repositories do not contain any hrev tags, which are used by the Haiku build system to determine the Haiku revision. To work around this limitation, use the HAIKU_REVISION build variable when building Haiku.

• Updating the Sources

  Be sure to use the --rebase argument while doing a pull prior to a push to avoid confusing nonlinear histories! ("Merge 'master' on ssh://git.haiku-os.org/haiku" messages showing your name and others changes) Do NOT however use --rebase on branches you have shared with other people! (rebase re-writes the local history. If your local history doesn't match people who cloned off of you, and they want to push to you, they will have major problems.)

  cd /path/haiku/haiku
  git pull --rebase
  

  Alternatively, a single path or multiple paths can be given to git pull. This will allow you to run the following command from any directory. This becomes extremely useful if you use an external object directory or if you wish to update both the buildtools and haiku directories at the same time.

  git pull --rebase /path/haiku/haiku /path/haiku/buildtools

• Making local commits

  In git you make commits to your local tree, then push the final results to the central remote Haiku repository. The comment quality of commits should be high, explaining changes in as much detail as possible.

  Short commit comment

  Short commit messages are best utilized for small changes or changes that hold a simple ideal.

  git commit -a -m “WebPositive: Style cleanup, no functional change”
  

  The short commit message should be a summary no longer than 64 characters, no returns

  Long commit comments

  Long commit messages are best used to explain what was changed and why on new code, rewrites, or other tasks that may need explanation.

  git commit -a -F ~/mycommitlog
  

  The following commit message format is recommended:

  kernel: Perform the usual early morning tasks
  
  
  
  Ensure cats in computer are fed.
  Clean up white space.
  The retroencabulator needs to be adjusted to accept input from
  multiple sources of data and ensure the buffer is free for
  shenanigans.
  No functional change.

  The first line should be a summary no longer than 64 characters, separated from a detailed description by a blank line. The description lines shouldn’t be longer than 72 characters.

• Pushing changes remotely

  git push
  

  After your changes are complete, the push command will push your local tree to the remote Haiku repository.

• Example git workflow