Penguin
Recent Changes
Blame: KernelDevelopmentWithGit
EditPageHistoryDiffInfoLikePages
Annotated edit history of KernelDevelopmentWithGit version 22, including all changes. View license author blame.
Rev Author # Line
11 IanMcDonald 1 The model for kernel development seems to be at present that everybody at one time or another clones off LinusTorvalds git tree and then creates a branch (see the howto on how to do this). You then make your changes and when you have a kernel that you like you produce patches off it and mail it out or you ask somebody to pull from your tree.
2
3 If you want to skip all the documentation and just make a clone of Linus' tree you can type:
4 <verbatim>
5 git-clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git mysourcedir
6 </verbatim>
7
20 IanMcDonald 8 When people talk about pulling or rebasing, all it really means is transferring the appropriate objects over. Provided you have created your own branch that is not a problem. It is not mentioned anywhere but because each change is given a unique number, provided that you have set up a branch (documented in <tt>howto</tt>), you can switch to a different [Git] and it works without losing your changes as most [Git]s are based around LinusTorvalds' [Git] tree and everybody just freely exchanges objects (files) around the [Git] trees. I would advise you to commit your objects before rebasing, otherwise a <tt>git checkout -f</tt> will blow your changes away, as rebasing usually changes the branch back to master rather than your own.
11 IanMcDonald 9
10 David Miller says this about pulling out patches:
11 > If you keep your <tt>.git/ORIG_HEAD</tt> sane, you can use a script like the following to pull your local changes out of a tree one-by-one. It drops them into a directory called <tt>patches/</tt> at the top-level and names them <tt>1.diff</tt>, <tt>2.diff</tt>, <tt>3.diff</tt>, etc. with changelogs prepended to the beginning. I call it <tt>git-mkpatches</tt>.
12
13 > <verbatim>
14 > #/bin/sh
15
16 > mkdir patches/
17
18 > count="1"
19 > for i in $(git-rev-list HEAD ^ORIG_HEAD | tac)
20 > do
21 > git-diff-tree --pretty -p ${i} > patches/$count.diff
22 > count=$(($count + 1))
23 > done
24 > </verbatim>
25
26 The best [Git] howto that I have found is http://linux.yyz.us/git-howto.html
27
28 Also more potentially useful information (untested by me -- IanMcDonald)
29
30 > Also, a bonus recipe: how to import Linus's pack files (it's easy).
31
32 > This recipe presumes that you have a vanilla-Linus repo (/repo/linux-2.6) and your own repo (/repo/myrepo-2.6).
33
34 > <verbatim>
35 > $ cd /repo/myrepo-2.6
36 > $ git-fsck-cache # fsck, make sure we're OK
37 > $ git pull /repo/linux-2.6/.git # make sure we're up-to-date
38 > $ cp -al ../linux-2.6/.git/objects/pack .git/objects
39 > $ cp ../linux-2.6/.git/refs/tags/* .git/refs/tags
40 > $ git-prune-packed
41 > $ git-fsck-cache # fsck #2, make sure we're OK
42 > </verbatim>
43
44 > This recipe reduced my kernel.org sync from ~50,000 files to ~5,000 files.
45
46 [Git] has got much better at merges now. In most cases the following commands will give you an updated kernel tree
47 <verbatim>
48 git pull
49 git-reset
50 </verbatim>
51
22 RobertStonehouse 52 The only exception to this is that it only pulls from the master tree.
11 IanMcDonald 53
54 If you want to then work on an older version then do the following for example if you want to work on 2.6.14:
55 <verbatim>
56 git-reset --hard v2.6.14
57 </verbatim>
22 RobertStonehouse 58
59 If you want to update to a tag older than 2.6.11 you will need to use a git repository that contains all the history that was in Bitkeeper.
11 IanMcDonald 60
20 IanMcDonald 61 Sometimes after doing a git-pull you can have fatal merge errors. The best way to resolve this is often to type git-reset.
11 IanMcDonald 62
63 If you get funny kernel version numbers when using [Git] it is a "feature" that can be turned off by unsetting CONFIG_LOCAL_VERSION. If you are in the menuconfig you can do this by going to General setup-->Automatically append version information to the version string.
64
65 Most [LinuxKernel] related [Git]s can be found at http://www.kernel.org/git/ which is where you should pull/rebase from if you are doing serious KernelDevelopment.
66
67 To make a copy of a git locally and quickly type the following:
68 <verbatim>
69 git-clone -l -s -n sourcedir/.git destdir
70 </verbatim>
71 This can be useful if you want to sync up to a new kernel tree and want to minimise downloads.
16 IanMcDonald 72
73 If you want to make a copy of a remote tree but reuse existing files that are stored locally do something like:
74 <verbatim>
75 git-clone --reference linus git://git.kernel.org/pub/scm/linux/kernel/git/acme/net-2.6.20.git acme-20
76 </verbatim>
77 This example creates a new git tree which is a copy of acme's remote one, stores it in the directory acme-20 but it also shares files with the git tree in linus. This can be very useful if you keep one tree of Linus' up to date and then keep making copies of other developers trees in this way as they change and can't be pulled easily after they get rebased.
11 IanMcDonald 78
79 !Using an origin file
80
81 If you want to do a git pull without having to specify where to get it from everytime edit the file .git/remotes/origin to be in this format where of course you change the URL:
82 <verbatim>
20 IanMcDonald 83 URL: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
11 IanMcDonald 84 Pull: master:origin
85 </verbatim>
86
20 IanMcDonald 87 In git version 1.5 the above has changed and the file is now in .git/config. There is also a new command git-remote for managing multiple remote repositories.
11 IanMcDonald 88
17 IanMcDonald 89 !Using git bisect
90
18 IanMcDonald 91 To use git bisect go to the bad code first (normally where you are at) and then type <tt>git bisect start</tt> and then <tt>git bisect bad</tt>
17 IanMcDonald 92
18 IanMcDonald 93 Now go to a place that is good by checking out code something like <tt>git-reset --hard v2.6.19-rc6</tt>. If that proves to be good then do <tt>git bisect good</tt> and then do each change marking good or bad with <tt>git bisect good</tt> or <tt>git bisect bad</tt> until you find the problem.
17 IanMcDonald 94
95 See also http://www.kernel.org/pub/software/scm/git/docs/howto/isolate-bugs-with-bisect.txt
11 IanMcDonald 96
97 Tip: Sometimes you lose track of where you came from so before you use git-bisect go into the .git directory and make a copy of the HEAD file so you know where you started! You can then always go back by typing:
98 <verbatim>
99 git-reset --hard COPY_HEAD
100 </verbatim>
101 where COPY_HEAD is your copy of HEAD....
12 IanMcDonald 102
103 However check the contents of the HEAD file as sometimes it's just a reference such as <tt>ref: refs/head/master</tt> in which case make a copy of that file which is being pointed to.
17 IanMcDonald 104
19 IanMcDonald 105 You can do this also by typing:
17 IanMcDonald 106 <verbatim>
19 IanMcDonald 107 git bisect reset master
108 git reset --hard FETCH_HEAD
17 IanMcDonald 109 </verbatim>
19 IanMcDonald 110 providing you want to go back to the last time you synced up.
13 IanMcDonald 111
112 !Working with branches
113
114 A key feature of git is to maintain branches of code. For example you might keep Linus' code and your own in separate branches.
115
116 To create a branch do the following:
117 <verbatim>
118 git-branch mybranch
119 </verbatim>
120
121 Now switch to it like:
122 <verbatim>
123 git-checkout mybranch
124 </verbatim>
125
126 If you want to merge back with a branch (e.g. master which is Linus' branch)
127 <verbatim>
128 git-merge "A comment" mybranch master
129 </verbatim>
14 IanMcDonald 130
131 !Series of patches
132
15 AristotlePagaltzis 133 There is a tool to help manage a series of patches called [Stacked Git | http://www.procode.org/stgit/] or stgit for short. The [Debian] [Package] is called <tt>stgit</tt>.
14 IanMcDonald 134
135 Basically you create a branch (see above) and then manage stacks of patches in this and resync upstream when you want to.
21 IanMcDonald 136
137 !Mailing patches. ArnaldoMelo says
138 <verbatim>
139 I use mutt for everything now, did it for years, then tried to use
140 thunderbird, evolution, kmail, you name it, ran away screaming back to
141 good old mutt + vi.
142
143 For sending patches I'll use git-send-email in the next DCCP batch, the
144 way it uses reply-to to chain patch series is awesome, and it'll save
145 lotsa time by being able to use it together with 'git-format-patch -n
146 origin', so, in summary what I do is:
147
148 1. git-clone --reference linus-2.6 davem-2.6 acme-2.6
149 2. hack away (these days, mostly merge like a turtle :-P)
150 3. GIT_AUTHOR_NAME="Gerrit" GIT_AUTHOR_EMAIL="gerrit@..." git-commit -a -s
151 4. git-format-patch -n origin
152 5. write 0000-patch-series.txt describing the patche series
153 6. push to master.kernel.org (that will be propagated to
154 www.kernel.org/git, etc)
155 7. git-send-email with 0000-patch-series.txt and what was produced in
156 step #4
157 8. rm -rf acme-2.6
158 9. hiatus, that thing called Real Work does a blunt, real time preempt
159 10. goto #1
160 </verbatim>
15 AristotlePagaltzis 161
11 IanMcDonald 162 ----
163 Part of CategoryKernel