OLD | NEW |
---|---|
(Empty) | |
1 # Use the Get the Code page | |
2 # DO NOT USE THIS PAGE | |
Bons
2015/08/20 20:16:51
remove
| |
3 | |
4 ``` | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 ``` | |
12 | |
13 * This page is superseded by [Get the Code](https://sites.google.com/a/chromiu m.org/dev/developers/how-tos/get-the-code) | |
14 * (prior to that, the [UsingGit](http://code.google.com/p/chromium/wiki/UsingG it) workflow page) | |
15 | |
16 **This page is kept around for historical purposes.** | |
17 | |
18 **Please only use the [Get the Code](https://sites.google.com/a/chromium.org/dev /developers/how-tos/get-the-code) page, thanks!** | |
19 | |
20 | |
21 ``` | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 ``` | |
29 | |
30 # Old workflow | |
31 | |
32 Some people working on Chromium prefer to use the Git version control system. Th is document offers advice and tips on using Git. | |
33 | |
34 **Warning: If you just `git clone` the Chromium repo, your checkout will not wor k.** A full checkout requires checking out around 100 other subprojects. | |
35 | |
36 | |
37 | |
38 # Getting the code | |
39 ## First checkout | |
40 | |
41 1. First, check the prerequisites for your platform: [Windows](http://dev.chro mium.org/developers/how-tos/build-instructions-windows), MacBuildInstructions, L inuxBuildInstructionsPrerequisites. | |
42 1. Make a new directory for working with Chromium and `cd` into it. | |
43 1. Download the [depot tools](http://dev.chromium.org/developers/how-tos/depot tools), which are used to fetch external dependencies of the code base. Here are Linux instructions; see [the install info](http://dev.chromium.org/developers/h ow-tos/install-depot-tools) for other platforms. Be sure to add the depot\_tools directory to your PATH. | |
44 ``` | |
45 git clone https://chromium.googlesource.com/chromium/tools/depot_tools | |
46 ``` | |
47 1. Grab the main tree with Git. You should be using git 1.6.6 or above in orde r to leverage "smart HTTP transport." **Using this exact name of output director y (`src`) is important!** This is a very large download, more than a gigabyte. You might get a smaller download via the `--depth` argument to `git clone`. | |
48 ``` | |
49 git clone https://chromium.googlesource.com/chromium/src | |
50 ``` | |
51 1. Create a `.gclient` config file. (If you are a committer, use should probab ly use `svn://svn.chromium.org/chrome/trunk/src` instead. This will check out de pendencies in a way that's compatible with `git cl` and `gcl`.) | |
52 | |
53 > -**NOTE:** Do this from the _parent_ of the `src` directory (the one you creat ed in step #2), otherwise it will create a new `src/` directory under your curre nt `src` directory. | |
54 ``` | |
55 gclient config http://src.chromium.org/chrome/trunk/src | |
56 ``` | |
57 1. _Optional._ Edit your `.gclient` file to avoid checking out the enormous s et of WebKit layout tests. Find the line that has an example of excluding a com ponent, and add beneath it (to the "custom\_deps" dictionary): | |
58 ``` | |
59 "src/third_party/WebKit/LayoutTests": None, | |
60 ``` | |
61 > Other things that are large and that you probable won't need that you can put there: | |
62 ``` | |
63 "src/chrome/tools/test/reference_build/chrome": None, | |
64 "src/chrome_frame/tools/test/reference_build/chrome": None, | |
65 "src/chrome/tools/test/reference_build/chrome_linux": None, | |
66 "src/chrome/tools/test/reference_build/chrome_mac": None, | |
67 ``` | |
68 > Specifying a safe-sync URL can be very helpful. Add the following to your .gc lient to ensure that only green builds will be synced: | |
69 ``` | |
70 "safesync_url": "http://chromium-status.appspot.com/lkgr", | |
71 ``` | |
72 1. Have gclient pull Chromium's dependencies as normal svn checkouts: | |
73 ``` | |
74 gclient sync | |
75 ``` | |
76 If all went well, gclient will recognize you're managing your `src` directory yo urself, and print the following at the very beginning. | |
77 ``` | |
78 ________ found .git directory; skipping src | |
79 ``` | |
80 Note that it will still check out other files such as tools and third party file s under the src directory. | |
81 | |
82 If you are using Linux, you may need to set certain environment variables before building. See LinuxBuildInstructions for more information. | |
83 | |
84 ### Advanced Tricks | |
85 * **WebKit and git.** See UsingWebKitGit and http://trac.webkit.org/wiki/Usin gGitWithWebKit. | |
86 | |
87 ## Staying up to date | |
88 1. Run `git pull` or whichever command is appropriate to update your checkout. The [Git community book](http://book.git-scm.com/) is a good resource to learn git from. | |
89 1. Run `gclient sync` if any of the `DEPS` files change to update dependent su bdirectories. | |
90 | |
91 # Contributing | |
92 ## Configure your checkout | |
93 Since contributing code using git requires git-cl, read git-cl's [README.coderev iew](http://src.chromium.org/viewvc/chrome/trunk/tools/depot_tools/README.codere view?view=markup) and [README.git-cl](http://src.chromium.org/viewvc/chrome/trun k/tools/depot_tools/README.git-cl?view=markup) to learn how to use it. Since yo u already have depot\_tools in your PATH, git-cl will "just work." | |
94 | |
95 You **must** add the junk to your ~/.subversion/config that's specified on http: //dev.chromium.org/developers/coding-style under "Subversion properties". Else g it won't set svn properties correctly and people might yell at you. That is not necessary if you use the [commit queue](http://www.chromium.org/developers/test ing/commit-queue) | |
96 | |
97 ## Making local changes | |
98 The first step to contributing a patch is to write it. Create a branch and make your changes: | |
99 ``` | |
100 git checkout -q -b mywork origin | |
101 vi ... | |
102 git commit -a -v | |
103 ``` | |
104 | |
105 ## Presubmit tests | |
106 After committing your changes locally, use git-cl to run all of the presubmit te sts associated with your change. | |
107 ``` | |
108 git cl presubmit | |
109 ``` | |
110 | |
111 This runs both upload and dcommit presubmit tests. They will alert you to any p roblems with your change that you should address before completing or dcommittin g your patch. | |
112 | |
113 There is currently a bug in the presubmit checks which will cause it to warn abo ut missing BUG and TEST fields even when they are present. These can be safely i gnored for now assuming the commit message contains those fields. | |
114 | |
115 ## Code Reviews | |
116 All code changes are reviewed using http://codereview.chromium.org. Use git-cl to easily upload a branch as a proposed change. | |
117 | |
118 You can associate each git branch you work on with a code review by running the following: | |
119 ``` | |
120 git checkout mywork | |
121 git cl upload | |
122 ``` | |
123 Uploading your change will also run the upload presubmit tests on your change. To skip the presubmit tests, use the flag --bypass-hooks. | |
124 | |
125 Subsequent invocations of 'upload' on the same branch will add updates to the sa me code review. See `git cl help` for more. | |
126 | |
127 ## Trybots | |
128 `git-try`, part of depot\_tools, will run git branches through the try bots. | |
129 | |
130 If your patch depends on specific branches in Chromium and WebKit, you can run g it-try with: | |
131 ``` | |
132 git try -t webkit_tests -s third_party/WebKit@WEBKIT_BRANCH | |
133 ``` | |
134 | |
135 where `WEBKIT_BRANCH` is branch or hash to compare with. | |
136 | |
137 ## Renames and Copies | |
138 Git has a strange notion of how copies and renames work; see [the Git FAQ about it](https://git.wiki.kernel.org/index.php/GitFaq#Why_does_git_not_.22track.22_re names.3F). If `git diff -M -C` shows that git knows a file was renamed, then `g it cl upload` and `git cl dcommit` will include the proper metadata for reviewin g and committing the rename. If not, ask `evan@chromium.org` about it -- this c ode isn't tested well so there are surely bugs. | |
139 | |
140 ## Committing | |
141 To commit from your checkout, you must (obviously) first have commit access. | |
142 | |
143 * **It is also important that you have a fairly recent version of Git -- 1.6.1 or so will do. Support for committing from a repository that is kept up to dat e with `git clone` was added only recently.** | |
144 * **Make sure you have git-svn package installed.** | |
145 * **Make sure to setup svn auto props,** as described here: http://dev.chromiu m.org/developers/coding-style#TOC-Subversion-properties | |
146 | |
147 ### Initial Setup | |
148 **Make sure you are in src/ folder when you run these commands: | |
149 ``` | |
150 git svn init --prefix=origin/ -T trunk/src svn://svn.chromium.org/chrome | |
151 git config svn-remote.svn.fetch trunk/src:refs/remotes/origin/git-svn | |
152 git svn fetch | |
153 ```** | |
154 | |
155 (If you're a git ninja, you might notice that `refs/remotes/origin` already poin ts at the git server, and we're telling git-svn that it should also use `refs/re motes/origin/trunk` -- we're instructing plain git and git-svn to use the same g it branch.) `fetch` rebuild its revision database. | |
156 | |
157 If any of your git svn commands appear to hang, you may have run the git svn ini t without the --prefix=origin/ and -T trunk/src arguments. | |
158 | |
159 ### Really Committing | |
160 Should Just Work. Always use `git cl dcommit`. It runs `git svn dcommit` for y ou along with running the very important presubmit tests. To bypass the presubm it tests (eg. to commit on a closed tree), use the flag --bypass-hooks. | |
161 | |
162 # Windows | |
163 Use cygwin with the following packages ([discussion against msysgit](UsingGit#Wh y_NOT_msysgit_or_TortoiseGit.md)): | |
164 * curl (for git-cl-patch) | |
165 * git | |
166 * git-svn | |
167 * gitk (optional) | |
168 * subversion-perl | |
169 * python | |
170 | |
171 After installation, sanity check your git-svn binaries by running "git svn info" . If you see an error message like below, you'll need to remap your binaries. | |
172 | |
173 **Be sure to turn off git's crlf munging AND disable file mode detection:** | |
174 ``` | |
175 git config --global core.autocrlf false | |
176 git config --global core.filemode false | |
177 ``` | |
178 | |
179 **Binaries may not work out of the box:** | |
180 | |
181 cygwin 1.7 (and also 1.5 on Windows 7) may throw error message like | |
182 ``` | |
183 $ git svn info | |
184 6 [main] perl 4760 C:\cygwin\bin\perl.exe: *** fatal error | |
185 - unable to remap <library> to same address as parent | |
186 ``` | |
187 while using git. You'll need to [rebase your dlls with ash.exe and 'rebaseall'] (http://www.dont-panic.cc/capi/2007/10/29/git-svn-fails-with-fatal-error-unable- to-remap/). | |
188 | |
189 If this doesn't work, you may need to get serious; see CygwinDllRemappingFailure for details | |
190 | |
191 **gclient may not work from cygwin shell:** | |
192 | |
193 "gclient runhooks" may fail when run from cygwin. Try this instead from cygwin: | |
194 | |
195 ``` | |
196 cmd /c gclient runhooks | |
197 ``` | |
198 | |
199 ## Workflow | |
200 [Here's a thread on chromium-dev](http://groups.google.com/a/chromium.org/group/ chromium-dev/browse_thread/thread/340d30c48702657) where people discuss Windows- specific workflow issues. In particular due to the slower filesystem and Visual Studio getting confused about files changing out from underneath it, you might want to avoid switching branches if possible, and instead use either only one br anch or `git-new-workdir`. See also the VanillaMsysgitWorkflow which takes a dif ferent approach, running all Chrome-specific git tools on a Linux box. | |
201 | |
202 ## Troubleshooting | |
203 Sometimes (it seems to happen on Windows, but not other platforms?) git-svn will get confused about things. Symptoms include it trying to refetch commits you'v e already fetched, or printing "transaction out of date" errors on unrelated fil es. | |
204 | |
205 Try this recipe: | |
206 ``` | |
207 rm -rf .git/svn # clobber git-svn metadata | |
208 git svn find-rev r1 # run a no-op command to rebuild metadata | |
209 ``` | |
210 | |
211 If you see errors about being unable to unlink old files when running git comman ds on Windows, it's quite likely that you have the chrome solution open in Visua l Studio and it's updating IntelliSense, which will briefly lock files at random . The workaround is either to disable IntelliSense entirely, or to be sure to cl ose the solution temporarily while performing any git operations which could tou ch a large number of files. | |
212 | |
213 ## Why NOT TortoiseGit | |
214 | |
215 The primary reason not to use TortoiseGit is speed. Chromium and Webkit reposito ries are too large for TortoiseGit to handle efficiently. TortoiseGit is too was teful in polling status and the UI is too often unresponsive in a workable manne r. | |
216 | |
217 msysgit got a lot better, and is considered by many to be much faster than cygwi n git. All the known issues we had with it were also fixed. The chrome infrastr ucture team recommends the use of msysgit. If you use msysgit and have problems , please let the chrome-infrastructure-team know. | |
218 | |
219 msysgit did appear to be functioning correctly after configuring autocrlf=false and filemode=false (pay attention during installation for that option to make li fe easy on yourself). | |
220 | |
221 Note: install msysgit to a location that is not controlled by antivirus software , e.g. c:\src (set not to be scanned). symlinks to git.exe in the libexec\git-co re folder may trip up scanning packages and cause the msys GUI to hang. | |
222 | |
223 Note that msysgit (as of 1.7.4-preview20110204) has a bug where it doesn't follo w config if it's a shortcut when changing it, breaking the shortcut. That means that the working directory style of using multiple git branches (use the new 'wi nsymlinks' CYGWIN setting, see http://cygwin.com/cygwin-ug-net/using-cygwinenv.h tml, or see https://github.com/joero74/git-new-workdir for a .cmd port that work s when run as admin) has extra caveats associated with it. Cygwin git is fine wi th working directories. | |
224 | |
225 Mixing Cygwin and msysgit can be done, but is fragile and unsupported. Not recom mended. The basic tactic is to isolate the two worlds by jumping back and forth using cmd.exe, but quoting issues are deadly here. Email 'scottbyer@chromium.org ' if you're determined. With an SSD for sources, the speed difference between th e two isn't dramatic enough to put up with the workflow interruptions. | |
226 | |
227 ## Using Pageant as SSH agent on Windows | |
228 | |
229 Some of those using git on Windows will constantly `git pull` and `git push` fro m/to a git repo on our Linux box (hint: you can even commit to running all try j obs and `git cl` commands from there). Having an SSH agent makes this a lot easi er since you don't have to provide your password every time git needs to SSH int o your Linux box. | |
230 | |
231 If you're using Cygwin, it's reasonably easy to just use the normal ssh-agent, y ou log in once after opening your Cygwin shell and that's it. | |
232 | |
233 On the other hand, for those using msysgit from a regular Windows command prompt (not from the bash shell that comes with msysgit), using Pageant (the SSH agent that comes with PuTTY) is a great solution. Here are the steps, roughly: | |
234 1. Set up PuTTY along with plink, puttygen and Pageant. | |
235 1. Follow the steps in chapters 8 and 9 of the [PuTTY documentation](http://th e.earth.li/~sgtatham/putty/0.60/htmldoc/) to generate your public/private key pa ir using puttygen, paste the public key into your ~/.ssh/authorized\_keys2 file (man sshd is your friend), and add the key to Pageant. Every time you start your machine (or when you want the SSH agent running), you will need to run Pageant, add the key, and provide the password to decrypt the key. | |
236 1. Set an environment variable GIT\_SSH to the full path of your plink.exe, e. g. `GIT_SSH=c:\tools\putty\plink.exe`. Remember that you may need to restart you r command prompt so that it picks this new variable up. | |
237 1. You're good to go. You can test by using PuTTY to SSH into your Linux box; PuTTY will automatically use a key from Pageant if available. Then run e.g. `git pull` to pull code from the git repo on your Linux box and it should just work. | |
238 | |
239 # Tips & Tricks | |
240 ## Finding Files Fast | |
241 | |
242 Use `git-gs` located in `src/depot_tools` to search the source tree. | |
243 | |
244 Since git keeps an index of all files it knows about, it can filter | |
245 the master list of files by file extension and only grep through those | |
246 files. It doesn't have to crawl your tree (and all those layout test | |
247 results) to grep over source code. Performing a `git gs [searchterm]` | |
248 from `/src/` gets results in a couple seconds with a cold disk. | |
249 It's often instant with a warm disk. | |
250 | |
251 Note this won't search dependencies pulled by gclient. | |
252 | |
253 ## Checking out and committing to a branch | |
254 Instructions per shess@. These instructions assume that you already have a clon e of the trunk repo. **If these destroy your git repo, please fix it yourself!* * | |
255 | |
256 ``` | |
257 BRANCH=552 ## Put your branch number here. | |
258 git config --add svn-remote.svn_$BRANCH.url svn://svn.chromium.org/chrome | |
259 git config --add svn-remote.svn_$BRANCH.fetch branches/$BRANCH/src:refs/remotes/ origin/$BRANCH | |
260 git svn fetch svn_$BRANCH | |
261 git checkout -b my_$BRANCH origin/$BRANCH | |
262 ``` | |
263 | |
264 From there, git cl dcommit commits to the right branch magically! git cl upload will also work correctly. Unfortunately, due to {bikeshed discussion omitted}, the DEPS file in the branch doesn't do the right thing. You need a per-release DEPS file to build correctly. Head over to http://omahaproxy.appspot.com/ and p ick your release, then: | |
265 | |
266 ``` | |
267 RELEASE=8.0.552.18 | |
268 cd .. ## cd to directory ABOVE src/. | |
269 gclient config http://src.chromium.org/chrome/releases/$RELEASE --gclientfile=.g client_$RELEASE | |
270 ## Consider editing .gclient_$RELEASE custom_deps to cut down on test data. | |
271 ``` | |
272 | |
273 Then, to checkout the branch: | |
274 | |
275 ``` | |
276 cd src/ | |
277 git checkout -b my_$BRANCH origin/$BRANCH | |
278 gclient sync --gclientfile=.gclient_$RELEASE --jobs 8 | |
279 ``` | |
280 | |
281 Note that the gclient file should be specified without a relative path, even tho ugh it's located in the directory above src/. | |
282 | |
283 As the branch gets further away from the trunk, the sync will start to see confl icts in src/third\_party. Usually these can just be deleted and the sync restar ted. As things diverge, re-syncing will get slower and slower (it may be worth using a symlinked .git repo). | |
284 | |
285 To get back to the trunk (may also require deletions in third\_party): | |
286 | |
287 ``` | |
288 cd .../src/ | |
289 git checkout my_trunk_branch | |
290 gclient sync --jobs 8 | |
291 ``` | |
292 | |
293 Also, if you need to merge changes to DEPS, see the internal ChromeReleaseBranch es wiki page for some notes. | |
294 | |
295 | |
296 ## Checking out trunk/tools | |
297 | |
298 ``` | |
299 git svn clone svn://svn.chromium.org/chrome -T trunk/tools | |
300 ``` | |
301 | |
302 We don't recommend fetching tools directly into your src/ checkout as the two ar e unrelated. You may want to fetch a subdirectory instead since tools/ is fairly large. | |
303 | |
304 ## Checking out LKGR | |
305 LKGR is based on an SVN revision, but there isn't always a git revision that map s exactly to a given SVN revision. If you'd like the low-level explanation of w hy this is true, take a look at the [layout of the chromium git repository](http ://www.chromium.org/developers/how-tos/git-repo). | |
306 | |
307 You may run the command `git lkgr` (which comes from `depot_tools/git-lkgr`) to find the git revision corresponding to the current LKGR: | |
308 | |
309 ``` | |
310 $ git lkgr | |
311 b21adba881ef1bfbae5acaf35dd41e3f3d3c44e5 | |
312 ``` | |
313 | |
314 If there is no git commit which corresponds exactly to LKGR, `git-lkgr` will off er to synthesize a local commit which corresponds **exactly** to LKGR: | |
315 | |
316 ``` | |
317 $ git lkgr | |
318 There is no master commit which corresponds exactly to lkgr. | |
319 The closest commit is b21adba881ef1bfbae5acaf35dd41e3f3d3c44e5. | |
320 Would you like to create a new branch based on lkgr? (y/N) y | |
321 ... | |
322 | |
323 -------------------------------------------------------------------------------- | |
324 The new branch "git_lkgr_r161345" was branched from this commit: | |
325 | |
326 44677576835e2b81ed659de1b1ca85b8fe525e5f | |
327 | |
328 ... which maps to the svn lkgr commit r161345. The new branch | |
329 has one additional commit, to bring .DEPS.git, .gitmodules, and the | |
330 invisible git submodule files up to date with DEPS. | |
331 | |
332 To create a working branch, do this: | |
333 | |
334 $ git branch --track my_new_branch git_lkgr_r161345 | |
335 | |
336 'git-cl upload' will do the right thing, i.e., it will cherry-pick all | |
337 your changes from my_new_branch, but *not* the .DEPS.git+.gitmodules+submodules | |
338 commit on git_lkgr_r161345. | |
339 -------------------------------------------------------------------------------- | |
340 | |
341 $ | |
342 ``` | |
OLD | NEW |