OLD | NEW |
(Empty) | |
| 1 depot_tools_tutorial(7) |
| 2 ======================= |
| 3 |
| 4 NAME |
| 5 ---- |
| 6 depot_tools_tutorial - A tutorial introduction to the Chromium depot_tools git |
| 7 extensions. |
| 8 |
| 9 DESCRIPTION |
| 10 ----------- |
| 11 |
| 12 The Chromium linkgit:depot_tools[7] suite contains many git workflow-enhancing |
| 13 tools which are designed to work together to enable anyone to wrangle the |
| 14 Chromium codebase expertly. This tutorial explains how to do development on |
| 15 Chromium using these tools. This will cover: |
| 16 |
| 17 * <<_setting_up,Setting up>> |
| 18 * <<_getting_the_code,Getting the code>> |
| 19 * <<_tl_dr_walkthrough,TL;DR Walkthrough>> |
| 20 * <<_creating_uploading_a_cl,Creating / Uploading a CL>> |
| 21 * <<_updating_the_code,Updating the code>> |
| 22 * <<_managing_multiple_cls,Managing multiple CLs>> |
| 23 * <<_managing_dependent_cls,Managing dependent CLs>> |
| 24 |
| 25 Please refer to the manpages (or `--help` output) for details about any of the |
| 26 commands mentioned in this tutorial. |
| 27 |
| 28 [NOTE] |
| 29 If your platform does not support manpages (or you prefer something a bit more |
| 30 expressive than plain text) you can find all documentation in 'html' form in the |
| 31 `[DEPOT_TOOLS]/docs/html` folder. |
| 32 |
| 33 PREREQUISITES |
| 34 ~~~~~~~~~~~~~ |
| 35 This tutorial assumes basic familiarity with git terminology and concepts. If yo
u |
| 36 need to brush up on these, the following are very good resources: |
| 37 |
| 38 * link:http://think-like-a-git.net/[Think like (a) Git] - A lighthearted |
| 39 overview of git. If you're sorta-familiar with git, but not 'comfortable' with |
| 40 it, then give this a look. |
| 41 * link:http://gitimmersion.com/[Git Immersion Tutorial] - An in-depth git |
| 42 tutorial. |
| 43 * link:http://pcottle.github.io/learnGitBranching[pcottle's Visual Git |
| 44 Branching] - An excellent interactive/graphical demo on how git handles |
| 45 commits, branches, and shows the operations git performs on them. |
| 46 * link:http://git-scm.com/book[Pro Git book] - ``The'' book for learning git |
| 47 from basics to advanced concepts. A bit dry, but very through. |
| 48 |
| 49 If you've tried these out and are still having some trouble getting started, |
| 50 there are 'many' other resources online which should help. If you're 'really' |
| 51 **'really'** stuck, then chat up one of the Chromium infrastructure team |
| 52 members for some pointers. |
| 53 |
| 54 Litmus Test:: |
| 55 If you know what `git add`, `git status`, `git commit` do and you know |
| 56 'essentially' what `git rebase` does, then you should know enough to follow |
| 57 along. |
| 58 |
| 59 SETTING UP |
| 60 ---------- |
| 61 |
| 62 GET DEPOT TOOLS |
| 63 ~~~~~~~~~~~~~~~ |
| 64 |
| 65 ifdef::backend-xhtml11[] |
| 66 LINUX / MAC |
| 67 ^^^^^^^^^^^ |
| 68 endif::backend-xhtml11[] |
| 69 Clone the 'depot_tools' repository: |
| 70 |
| 71 [subs="quotes"] |
| 72 ---- |
| 73 [white]**$ git clone https://chromium.googlesource.com/chromium/tools/depot_tool
s** |
| 74 ---- |
| 75 |
| 76 Add 'depot_tools' to the 'end' of your PATH and MANPATH (you will probably want |
| 77 to put this in your `~/.bashrc` or `~/.zshrc`). Assuming you cloned |
| 78 'depot_tools' to `/path/to/depot_tools`: |
| 79 |
| 80 [postsubs="quotes"] |
| 81 ---- |
| 82 [white]**$ export PATH=$PATH:/path/to/depot_tools** |
| 83 [white]**$ export MANPATH=$MANPATH:/path/to/depot_tools/docs** <1> |
| 84 ---- |
| 85 <1> Observe that this path is +depot_tools/+**+docs+**. |
| 86 |
| 87 // No need to show the Windows stuff on the manpage output. |
| 88 ifdef::backend-xhtml11[] |
| 89 WINDOWS |
| 90 ^^^^^^^ |
| 91 Download the 'depot_tools' |
| 92 link:https://src.chromium.org/svn/trunk/tools/depot_tools.zip[bundle] and |
| 93 extract it somewhere. |
| 94 |
| 95 [WARNING] |
| 96 *DO NOT* use drag-n-drop or copy-n-paste extract from Explorer, this will not |
| 97 extract the hidden ``.git'' folder which is necessary for 'depot_tools' to |
| 98 autoupdate itself. You can use ``Extract all...'' from the context menu though. |
| 99 |
| 100 Add 'depot_tools' to the 'end' of your PATH. Assuming you unzipped the |
| 101 bundle to `C:\workspace\depot_tools`: |
| 102 |
| 103 With Administrator access: :: |
| 104 *Control Panel -> System and Security -> System -> Advanced system settings* |
| 105 + |
| 106 Modify the PATH system variable to include `C:\workspace\depot_tools`. |
| 107 |
| 108 Without Administrator access: :: |
| 109 *Control Panel -> User Accounts -> User Accounts -> Change my environment vari
ables* |
| 110 + |
| 111 Add a PATH user variable: `%PATH%;C:\workspace\depot_tools`. |
| 112 |
| 113 From a `cmd.exe` shell, run the command `gclient` (without arguments). On first |
| 114 run, gclient will install all the Windows-specific bits needed to work with the |
| 115 code, including msysgit and python. |
| 116 |
| 117 [NOTE] |
| 118 ===== |
| 119 * If you run gclient from a non-cmd shell (e.g., cygwin, PowerShell), it |
| 120 may appear to run properly, but msysgit, python, and other tools may not get |
| 121 installed correctly. |
| 122 * If you see strange errors with the file system on the first run of gclient, |
| 123 you may want to link:http://tortoisesvn.tigris.org/faq.html#cantmove2[disable |
| 124 Windows Indexing]. |
| 125 * If you are running Windows XP and see errors like ``The system cannot execute |
| 126 the specified program'', try installing the |
| 127 link:http://code.google.com/p/chromium/issues/detail?id=75886[``Microsoft |
| 128 Visual C++ 2008 Redistributable Package'']. |
| 129 ===== |
| 130 endif::backend-xhtml11[] |
| 131 |
| 132 BOOTSTRAPPING CONFIGURATION |
| 133 ~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 134 If you have never used git before, you’ll need to set some global git |
| 135 configurations; substitute your name and email address in the following |
| 136 commands: |
| 137 |
| 138 [subs="quotes,attributes"] |
| 139 ---- |
| 140 [white]**$ git config --global user.name ``John Doe''** |
| 141 [white]**$ git config --global user.email ``jdoe@email.com''** |
| 142 [white]**$ git config --global core.autocrlf false** |
| 143 [white]**$ git config --global core.filemode false** |
| 144 [white]**$** # and for fun! |
| 145 [white]**$ git config --global color.ui true** |
| 146 ---- |
| 147 |
| 148 GETTING THE CODE |
| 149 ---------------- |
| 150 Pick an empty directory and run one of the following: |
| 151 |
| 152 [subs="quotes"] |
| 153 ---- |
| 154 [white]**$ fetch chromium** # Basic checkout for desktop Chromium |
| 155 [white]**$ fetch blink** # Chromium code with Blink checked out to tip-of-tr
ee |
| 156 [white]**$ fetch android** # Chromium checkout for Android platform |
| 157 [white]**$ fetch ios** # Chromium checkout for iOS platform |
| 158 ---- |
| 159 |
| 160 When the `fetch` tool completes you should have the following in your working |
| 161 directory: |
| 162 |
| 163 [subs="quotes"] |
| 164 ---- |
| 165 [white]**.gclient** # A configuration file for you source checkout |
| 166 [white]**src/** # Top-level Chromium source checkout. |
| 167 ---- |
| 168 |
| 169 If you are on linux, then you'll need to run: |
| 170 |
| 171 [subs="specialcharacters,quotes"] |
| 172 ---- |
| 173 [white]**$ cd src && ./build/install-build-deps.sh** |
| 174 ---- |
| 175 |
| 176 And finally: |
| 177 |
| 178 [postsubs="quotes"] |
| 179 ---- |
| 180 [white]**$ gclient sync** <1> |
| 181 ---- |
| 182 <1> This will pull all dependencies of the Chromium src checkout. You will need |
| 183 to run this any time you update the main src checkout. |
| 184 |
| 185 |
| 186 TL;DR WALKTHROUGH |
| 187 ----------------- |
| 188 This section will demo what a typical workflow looks like when writing, updating
, |
| 189 and committing multiple CLs. |
| 190 |
| 191 demo:tldr[] |
| 192 |
| 193 So there you have the basic flow. Note that you don't 'have' to do chromium |
| 194 development using these tools. Any git workflow is compatible, as long as |
| 195 `git cl upload` is able to upload good patches. |
| 196 |
| 197 |
| 198 CREATING / UPLOADING A CL |
| 199 ------------------------- |
| 200 NOTE: The remainder of the tutorial assumes that your current working directory |
| 201 is the `src/` folder mentioned in <<_getting_the_code,Getting the code>>. |
| 202 |
| 203 Each CL corresponds exactly with a single branch in git. Any time you want to |
| 204 begin a new CL, just: |
| 205 |
| 206 [subs="specialcharacters,quotes"] |
| 207 ---- |
| 208 [white]**$ git new-branch <branch_name>** |
| 209 ---- |
| 210 |
| 211 This will create and checkout a new branch named `branch_name` which will track |
| 212 the default upstream (which is `origin/master`). See linkgit:git-new-branch[1] |
| 213 for more features, such as the ability to track 'LKGR'. |
| 214 |
| 215 Commit as many changes as you like to this branch. When you want to upload it |
| 216 for review, run: |
| 217 |
| 218 [subs="quotes"] |
| 219 ---- |
| 220 [white]**$ git cl upload** |
| 221 ---- |
| 222 |
| 223 This will take the diff of your branch against its upstream (`origin/master`), |
| 224 and will post it to the link:https://codereview.chromium.org[Chromium code |
| 225 review site]. |
| 226 |
| 227 |
| 228 UPDATING THE CODE |
| 229 ----------------- |
| 230 Inevitably, you'll want to pull in changes from the main Chromium repo. This is |
| 231 pretty easy with 'depot_tools': |
| 232 |
| 233 [subs="quotes"] |
| 234 ---- |
| 235 [white]**$ git rebase-update** |
| 236 ---- |
| 237 |
| 238 This command will update all of your CLs to contain the latest code from their |
| 239 upstreams. It will also automatically clean up CLs which have been committed and |
| 240 a couple other nice things. See linkgit:git-rebase-update[1] for the full |
| 241 scoop. |
| 242 |
| 243 One thing to look out for are 'merge conflicts'. These happen for exactly the |
| 244 same as they do with SVN, but the experience is a little more controllable with |
| 245 git. `git rebase-update` will try to rebase all your branches for you, but if it |
| 246 encounters a merge conflict in one, it will halt and leave you in a rebase |
| 247 conflict state (see linkgit:git-rebase[1]). Resolving `git rebase` merge |
| 248 conflicts is beyond the scope of this tutorial, but there are many good sources |
| 249 online (see the <<_prerequisites,Prerequisites>> for some). |
| 250 |
| 251 Sometimes you're pretty certain that you've committed a certain branch, but `git |
| 252 rebase-update` isn't able to tell that for sure. This is usually because your |
| 253 branch doesn't rebase cleanly. You could just delete the branch with `git branch |
| 254 -D <branch>`, but you'd like to double check the diff of your branch against its |
| 255 upstream before deleting it. If this is the case you can abort the rebase |
| 256 started by `git rebase-update`, and then run linkgit:git-squash-branch[1] to |
| 257 flatten your branch into a single commit. When you run `git rebase-update` |
| 258 again, you'll get a (hopefully) much smaller / saner diff. If it turns out you |
| 259 were wrong about your branch being fully committed, you can use |
| 260 linkgit:git-reflog[1] to reset your branch back to where it was before. If the |
| 261 diff looks inconsequential, you can use `git rebase --skip` to ignore it, and |
| 262 then `git rebase-update` will clean it up for you. |
| 263 |
| 264 Once you're done resolving all of the merge conflict, just run `git |
| 265 rebase-update`, and it will pick up where it left off. Once the command has |
| 266 finished updating all of your branches, it will return you back to the branch |
| 267 you started on. |
| 268 |
| 269 [NOTE] |
| 270 Running `git rebase-update` will update all your branches, but it will not |
| 271 automatically run `gclient sync` to update your dependencies. |
| 272 |
| 273 |
| 274 MANAGING MULTIPLE CLS |
| 275 --------------------- |
| 276 Sometimes you want to work on more than one CL at once (say, you have a CL |
| 277 posted for review and want to work on something else). For each CL that you |
| 278 want to work on, just use `git new-branch <branchname>`. |
| 279 |
| 280 Once you start to have more than one CL at a time, it can be easy to lose your |
| 281 bearings. Fortunately, 'depot_tools' has two tools to help you out: |
| 282 |
| 283 [subs="specialcharacters,quotes,attributes"] |
| 284 ---- |
| 285 [white]**$ git map** |
| 286 [white blue-background]##*##{zwsp}[blue-background red]** 7dcfe47 ** [gree
n]##(##{zwsp}[aqua]**frozen_changes**{zwsp}[green]##)## [yellow]##2014-03-12## \
~ FREEZE.unindexed |
| 287 * [red]**4b0c180** [yellow]##2014-03-12## \~ modfile |
| 288 * [red]**59a7cca** [yellow]##2014-03-12## \~ a deleted file |
| 289 * [red]**6bec695** [green]##(##{zwsp}[red]##origin/master##{zwsp}[green]#
#)## [yellow]##2014-03-11## \~ Add neat feature [white]**<(frozen_changes)** |
| 290 * [red]**d15a38a** [yellow]##2014-03-11## \~ Epic README update |
| 291 * [red]**d559894** [green]##(##{zwsp}[lime]**master**{zwsp}[green]##)## [
yellow]##2014-03-11## \~ Important upstream change |
| 292 [red]##|## * [red]**9c311fd** [green]##(##{zwsp}[lime]**cool_feature**{zwsp
}[green]##)## [yellow]##2014-03-11## \~ Respond to CL comments |
| 293 [red]##|## [green]##|## * [red]**2a1eeb2** [green]##(##{zwsp}[lime]**subfeatu
re**{zwsp}[green]##)## [yellow]##2014-03-11## \~ integrate with CoolService |
| 294 [red]##|## [green]##|## * [red]**d777af6** [yellow]##2014-03-11## \~ slick co
mmenting action |
| 295 [red]##|## [green]##|/## |
| 296 [red]##|## * [red]**265803a** [yellow]##2014-03-11## \~ another improvement
[white]**<(subfeature)** |
| 297 [red]##|## * [red]**6d831ac** [green]##(##{zwsp}[fuchsia]**spleen_tag**{zws
p}[green]##)## [yellow]##2014-03-11## \~ Refactor spleen |
| 298 [red]##|## * [red]**82e74ab** [yellow]##2014-03-11## \~ Add widget |
| 299 [red]##|/## |
| 300 * [red]**d08c5b3** [green]##(##{zwsp}[lime]**bogus_noparent**{zwsp}[green
]##)## [yellow]##2014-03-11## ~ Wonderful beginnings [white]**<(cool_feature)
** |
| 301 ---- |
| 302 Note that this example repo is in dire need of a linkgit:git-rebase-update[1]! |
| 303 |
| 304 [subs="quotes"] |
| 305 ---- |
| 306 [white]**$ git map-branches** |
| 307 [red]#origin/master# |
| 308 [green]#cool_feature# |
| 309 [green]#subfeature# |
| 310 [aqua]#frozen_changes *# |
| 311 [green]#master# |
| 312 ---- |
| 313 |
| 314 linkgit:git-map[1]:: |
| 315 This tool shows you the history of all of your branches in a pseudo-graphical |
| 316 format. In particular, it will show you which commits all of your branches |
| 317 are on, which commit you currently have checked out, and more. Check out the |
| 318 doc for the full details. |
| 319 |
| 320 linkgit:git-map-branches[1]:: |
| 321 This tool just shows you which branches you have in your repo, and thier |
| 322 upstream relationship to each other (as well as which branch you have checked |
| 323 out at the moment). |
| 324 |
| 325 Additionally, sometimes you need to switch between branches, but you've got work |
| 326 in progress. You could use linkgit:git-stash[1], but that can be tricky to |
| 327 manage because you need to remember which branches you stashed what changes on. |
| 328 Helpfully 'depot_tools' includes two tools which can greatly assist in case: |
| 329 |
| 330 linkgit:git-freeze[1] allows you to put the current branch in \'suspended |
| 331 animation' by committing your changes to a specially-named commit on the top of |
| 332 your current branch. When you come back to your branch later, you can just run |
| 333 linkgit:git-thaw[1] to get your work-in-progress changes back to what they were. |
| 334 |
| 335 Another useful tool is linkgit:git-rename-branch[1]. Unlike `git branch -m <old> |
| 336 <new>`, this tool will correctly preserve the upstream relationships of your |
| 337 branch compared to its downstreams. |
| 338 |
| 339 Finally, take a look at linkgit:git-upstream-diff[1]. This will show you the |
| 340 combined diff for all the commits on your branch against the upstream tracking |
| 341 branch. This is 'exactly' what `git cl upload` will push up to code review. |
| 342 Additionally, consider trying the `--wordwise` argument to get a colorized |
| 343 per-word diff (instead of a per-line diff). |
| 344 |
| 345 MANAGING DEPENDENT CLS |
| 346 ---------------------- |
| 347 Now that you know how to manage 'independent' CLs, we'll see how to manage |
| 348 'dependent' CLs. Dependent CLs are useful when your second (or third or fourth |
| 349 or ...) CL depends on the changes in one of your other CLs (such as: CL 2 won't |
| 350 compile without CL 1, but you want to submit them as two separate reviews). |
| 351 |
| 352 Like all of the other CLs we've created, we use linkgit:git-new-branch[1], but |
| 353 this time with an extra argument. First, `git checkout` the branch |
| 354 you want to base the new one on (i.e. CL 1), and then run: |
| 355 |
| 356 [subs="specialcharacters,quotes"] |
| 357 ---- |
| 358 [white]**$ git new-branch --upstream_current <branch_name>** |
| 359 ---- |
| 360 |
| 361 This will make a new branch which tracks the 'current' branch as its upstream |
| 362 (as opposed to 'origin/master'). All changes you commit to this branch will be |
| 363 in addition to the previous branch, but when you `git cl upload`, you will only |
| 364 upload the diff for the dependent (child) branch. You may have as many branches |
| 365 nested in this fashion as you like. |
| 366 |
| 367 linkgit:git-map[1] and linkgit:git-map-branches[1] are particularly helpful when |
| 368 you have dependent branches. In addition, there are two helper commands which |
| 369 let you traverse your working copy up and down this tree of branches: |
| 370 linkgit:git-nav-upstream[1] and linkgit:git-nav-downstream[1]. |
| 371 |
| 372 Sometimes when dealing with dependent CLs, it turns out that you accidentally |
| 373 based a branch on the wrong upstream, but since then you've committed changes to |
| 374 it, or even based 'another' branch off of that one. Or you discover that you |
| 375 have two independent CLs that would actually be much better off as dependent |
| 376 CLs. In instances like these, you can check out the offending branch and use |
| 377 linkgit:git-reparent-branch[1] to move it to track a different parent. Note that |
| 378 this can also be used to move a branch from tracking `origin/master` to `lkgr` |
| 379 or vice versa. |
| 380 |
| 381 |
| 382 CONCLUSION |
| 383 ---------- |
| 384 Hopefully that gives you a good starting overview on Chromium development using |
| 385 'depot_tools'. If you have questions which weren't answered by this tutorial or |
| 386 the man pages for the tools (see the index of all tools here: |
| 387 linkgit:depot_tools[7]), please feel free to ask. |
| 388 |
| 389 |
| 390 GLOSSARY |
| 391 -------- |
| 392 |
| 393 CL:: |
| 394 A 'change-list'. This is a diff which you would like to commit to the |
| 395 codebase. |
| 396 |
| 397 DEPS:: |
| 398 A file in the chromium checkout which `gclient sync` uses to determine what |
| 399 dependencies to pull in. This file also contains 'hooks'. |
| 400 |
| 401 LKGR:: |
| 402 Last Known Good Revision. This is a linkgit:git-tag[1] which tracks the last |
| 403 version of `origin/master` which has passed the full set of testing on the |
| 404 link:http://build.chromium.org[main Chromium waterfall]. |
| 405 |
| 406 include::_footer.txt[] |
| 407 |
| 408 // vim: ft=asciidoc: |
OLD | NEW |