1 # Mastering the DragonFly git repository
4 ## Clone the repository
7 First you go in your work directory and clone the DragonFly repository. While ***crater*** is the official repo, you are urged to use one of our (generally much faster) mirrors instead.
9 > git clone -o chlamydia git://chlamydia.fs.ei.tum.de/dragonfly.git
15 If you are a developer, you should create a ***remote*** entry for pushing to ***crater***:
19 > git remote add crater ssh://crater.dragonflybsd.org/repository/git/dragonfly.git
25 Clone creates remote-tracking branches for all branches in the parent repo and creates a local **master** branch from the remote **master** branch.
36 chlamydia/DragonFly_RELEASE_1_10
38 chlamydia/DragonFly_RELEASE_1_12
40 chlamydia/DragonFly_RELEASE_1_2
42 chlamydia/DragonFly_RELEASE_1_4
44 chlamydia/DragonFly_RELEASE_1_6
46 chlamydia/DragonFly_RELEASE_1_8
48 chlamydia/DragonFly_RELEASE_2_0
56 chlamydia/vendor/ATHEROS
70 If you (as a non-developer) made some changes to the DragonFly source and want to get them included in the main repository, send your patches to submit@lists.dragonflybsd.org. git assists you in creating patches which are easy to handle for the developers.
76 **Note:** The change in this example is completely useless, it only serves demonstration purposes!
80 At first edit the files you want to change:
88 Then review your changes with `git diff`:
94 diff --git a/README b/README
96 index 495a262..6a95d1f 100644
102 @@ -59,7 +59,7 @@ lib System libraries.
106 libexec System daemons.
110 -nrelease Framework for building the ***live*** CD image.
112 +nrelease Framework for building the ***live CD*** image.
116 sbin System commands.
122 If you are satisfied with your changes, commit them. **Note:** The first line of your commit message should describe your change in a small sentence. Add more details after one newline.
128 ".git/COMMIT_EDITMSG" 10L, 342C written
130 Created commit cbb871b: Change parentheses
132 1 files changed, 1 insertions(+), 1 deletions(-)
136 Now you can use `git format-patch` to generate a patch file. This file is ready for submission to submit@. `git format-patch` will generate one file for every commit you did.
140 > git format-patch origin
142 0001-Change-parentheses.patch
144 > cat 0001-Change-parentheses.patch
146 From cbb871b4588c695f000bc701b4f3c16a0a518991 Mon Sep 17 00:00:00 2001
148 From: Matthias Schmidt <matthiasdragonflybsd.org>
150 Date: Tue, 2 Dec 2008 09:54:47 +0100
152 Subject: [PATCH] Change parentheses
160 1 files changed, 1 insertions(+), 1 deletions(-)
164 diff --git a/README b/README
166 index 495a262..6a95d1f 100644
172 @@ -59,7 +59,7 @@ lib System libraries.
176 libexec System daemons.
180 -nrelease Framework for building the ***live*** CD image.
182 +nrelease Framework for building the ***live CD*** image.
186 sbin System commands.
200 Attach the generated files to a mail and submit it. Write some lines about your intention and why you changed what ...
204 ## Working with branches
206 It is **not** recommended to work directly in your **master** branch, except maybe for one-liners. Branches in git are very cheap, so just keep your **master** branch pure, and always work on a different local branch.
210 Say you want to work on a simple change. Just create a temporary branch, make the change and commit it.
217 > git checkout -b work # you're now in the work branch
227 Now, you can switch back to **master** , merge in the changes in your **work** branch and push away:
233 > git checkout master # you're now in the master branch
235 > git merge work # now master has your changes
241 Afterwards, you may (or not, if you want to do further development) want to delete the **work** branch by
253 For more complex changes, you probably want to create a longer-lived branch. For example
259 > git checkout -b myfeature
265 You can work in the **myfeature** branch until your feature is ready. You can commit there as often as you like. If your work goes on for a significant amount of time, you will want to merge with the upstream **master** from time to time. It is recommended that you use git rebase, so that the merge points won't show up in the repo history on crater (they don't really add much information). For this, you'd do:
271 > git checkout master
275 > git checkout myfeature
283 ## Push your work upstream
285 When you judge that your code is ready for inclusion in mainline, you can merge it into your local **master** branch and push away:
291 > git checkout master
293 > git merge myfeature
301 as the command will not push any branch that is not in the remote repository.