1Haiku Git Repositories 2====================== 3 4Haiku uses Git for source control, combined with Gerrit for review of code changes. 5 6Most of the operating system sources are stored in a single repository at http://cgit.haiku-os.org/haiku . 7 8Another repository at http://cgit.haiku-os.org/buildtools contains the build tools, that is, gcc, 9binutils, and Jam, which are maintained by Haiku developers. 10 11`Additional repositories <https://github.com/orgs/haiku/repositories>`_ are hosed on GitHub. 12 13Finally, some pre-compiled packages are downloaded during the build, these are built using 14Haikuporter from `recipes available here <https://github.com/orgs/haikuports/repositories>`_. 15 16Getting the sourcecode 17---------------------- 18 19 * https://www.haiku-os.org/guides/building/get-source-git 20 21Sending change reviews 22---------------------- 23 24 * https://dev.haiku-os.org/wiki/CodingGuidelines/SubmittingPatches 25 * https://review.haiku-os.org/Documentation/user-upload.html 26 27Managing GCC and binutils updates using vendor branches 28------------------------------------------------------- 29 30The buidtools repository uses vendor branches. This concept originates from `the SVN Book <https://svnbook.red-bean.com/en/1.8/svn.advanced.vendorbr.html>`_ 31but applies just as well to Git. This organization allows to clearly separate the imported code 32from upstream, and the changes we have made to it. 33 34The idea is to import all upstream changes in a dedicated branch (there are currently two, called 35vendor-gcc and vendor-binutils). These branches contains the sources of gcc and binutils as 36distributed by the GNU project, without any Haiku changes. 37 38The master branch can then merge new versions from the vendor branches. This allows to use Git 39conflict resolution to make sure our patches are correctly ported from one version to the next. 40 41It also makes it easy to compare the current state of our sourcecode with the upstream code, for 42example to extract patches that could be upstreamed. 43 44How to import upstream changes 45.............................. 46 47Here is an example of the process used to update to a new version of binutils: 48 49.. code-block:: bash 50 51 git checkout vendor-binutils # Move to the branch containing binutils 52 git rm -rf binutils ; rm -rf binutils # Delete the existing version of binutils 53 wget http://.../binutils-2.36.tar.xz # Download the latest version 54 tar xf binutils-2.36.tar.xz # Extract the new binutils version 55 mv binutils-2.36 binutils # Move the extracted files to the right place 56 git add -f binutils # Add the new files to git 57 git commit -m "import binutils 2.36" # Commit the files in the vendor branch 58 git push origin vendor-binutils # You can push this directly to the branch 59 60Now this can easily be merged into the master branch: 61 62.. code-block:: bash 63 64 git checkout master 65 git merge vendor-binutils 66 67Review and fix the conflicts, if any, then push the changes for review on Gerrit. 68 69Comparing our code with upstream 70................................ 71 72Comparing the two versions is easy because you can refer to them by branch names: 73 74.. code-block:: bash 75 76 git diff vendor-binutils master -- binutils 77