Upgrade V8 to 7.2.502.16

.gitignore

@@ -9,10 +9,10 @@
 /rust_crates/registry/cache/
 /rust_crates/registry/index/
 
-/v8/buildtools/*/clang-format
-/v8/buildtools/*/gn
-/v8/buildtools/win/*.exe
-/v8/third_party/llvm-build/
+v8/buildtools/*/clang-format
+v8/buildtools/*/gn
+v8/buildtools/win/*.exe
+v8/third_party/llvm-build/
 
 # Outdated Rust crates for which we are already using a newer version.
 /rust_crates/registry/**/rand-0.4.*/

cpplint/.gitignore

@@ -0,0 +1,2 @@
+# Python compiled files
+*.pyc

depot_tools/.gitattributes

@@ -0,0 +1,54 @@
+# The `recipes` attribute controls which additional files are included in the
+# recipes bundle when running the `//recipes/recipes.py bundle` command. These
+# files will also be available to other repos' recipes when they pull in
+# depot_tools as a recipe dependency.
+
+# Tools
+/*.bat recipes
+/*.exe recipes
+/*.py  recipes
+/*.sh  recipes
+
+# vpython specs
+/gsutil.vpython recipes
+
+# Extensionless tools we want and support scripts.
+/clang*                       recipes
+/depot-tools-auth             recipes
+/download_from_google_storage recipes
+/fetch                        recipes
+/gclient                      recipes
+/git*                         recipes
+/gn                           recipes
+/ninja*                       recipes
+/pylint*                      recipes
+/repo                         recipes
+/roll-dep*                    recipes
+/yapf*                        recipes
+
+# Symlinks
+/cbuildbot      recipes
+/chrome_set_ver recipes
+/cros*          recipes
+
+/support/* recipes
+
+# TODO: There are some really junky dependencies in here that we should probably
+# move to vpython/cipd.
+/third_party/**                     recipes
+/third_party/pymox/**              -recipes
+
+/win_toolchain/** recipes
+
+/fetch_configs/*.py recipes
+
+# Some things we never need to include in the bundle
+*.diff         -recipes
+*LICENSE*      -recipes
+*README*       -recipes
+.gitattributes -recipes
+.gitignore     -recipes
+COPYING        -recipes
+MANIFEST.in    -recipes
+OWNERS         -recipes
+PKG-INFO       -recipes

depot_tools/.gitignore

@@ -0,0 +1,83 @@
+# Ignore any python bytecode.
+*.pyc
+
+# ignore cipd client files
+/.cipd_bin
+/.cipd_client*
+/.versions
+
+# Ignore "disable auto update" sentinel file.
+.disable_auto_update
+
+# Ignore the batch files produced by the Windows bootstrapping.
+/git-bash
+/git.bat
+/gitk.bat
+/pylint.bat
+/.pylint.d/
+/python
+/python.bat
+/ssh.bat
+/ssh-keygen.bat
+/svn
+/svn.bat
+/svnversion.bat
+/.bleeding_edge
+/.codereview_upload_cookies
+/.gitconfig
+/.git_bleeding_edge
+/.git_cl_description_backup
+/.last_codereview_email_address
+/.ssh
+/.subversion
+
+# Ignore locations where third-party tools are placed during bootstrapping.
+/python*_bin
+/python_bin_reldir.txt
+/win_tools*_bin
+/git_bin
+/git-*_bin
+/svn_bin
+/external_bin
+/win_toolchain/vs2013_files
+/win_toolchain/vs_files
+/win_toolchain/*.timestamps
+/win_toolchain/.vspro
+/win_toolchain/data.json
+/win_toolchain/vs_files.ciopfs
+
+# Ignore ctags/cscope index files
+/TAGS
+/cscope.files
+/cscope.in.out
+/cscope.out
+/cscope.po.out
+/tags
+
+# Ignore unittest related files.
+/testing_support/_infra
+/testing_support/_rietveld
+/tests/git-svn-submodule/
+/tests/subversion_config/README.txt
+/tests/subversion_config/auth
+/tests/subversion_config/servers
+/tests/svn/
+/tests/svnrepo/
+
+# Ignore intermediate isolate files
+*.isolated
+*.isolated.state
+
+# Ignore recipe working directory.
+/.recipe_deps
+/infra/.recipe_deps
+/recipes/.recipe_deps
+
+# Ignore google AE downloaded for running testing only.
+testing_support/google_appengine
+
+# Ignore emacs / vim backup files.
+*~
+
+# Ignore the monitoring config. It is unique for each user.
+/metrics.cfg

depot_tools/README.git-cl.md

@@ -0,0 +1,113 @@
+# git-cl
+
+The git-cl README describes the git-cl command set. This document describes how
+code review and git work together in general, intended for people familiar with
+git but unfamiliar with the code review process supported by Rietveld and
+Gerrit.
+
+
+## Rietveld concepts and terms
+
+A Rietveld review is for discussion of a single change or patch. You upload a
+proposed change, the reviewer comments on your change, and then you can upload a
+revised version of your change. Rietveld stores the history of uploaded patches
+as well as the comments, and can compute diffs in between these patches. The
+history of a patch is very much like a small branch in git, but since Rietveld
+is VCS-agnostic, the concepts don't map perfectly. The identifier for a single
+review thread including patches and comments in Rietveld is called an **issue**.
+
+Rietveld provides a basic uploader that understands git. This program is used by
+git-cl, and is included in the git-cl repo as upload.py.
+
+
+## Basic interaction with git
+
+The fundamental problem you encounter when you try to mix git and code review is
+that with git it's nice to commit code locally, while during a code review
+you're often requested to change something about your code. There are a few
+different ways you can handle this workflow with git:
+
+1. Rewriting a single commit. Say the origin commit is O, and you commit your
+   initial work in a commit A, making your history like O--A. After review
+   comments, you `git commit --amend`, effectively erasing A and making a new
+   commit A', so history is now O--A'. (Equivalently, you can use
+   `git reset --soft` or `git rebase -i`.)
+2. Writing follow-up commits. Initial work is again in A, and after review
+   comments, you write a new commit B so your history looks like O--A--B. When
+   you upload the revised patch, you upload the diff of O..B, not A..B; you
+   always upload the full diff of what you're proposing to change.
+
+The Rietveld patch uploader just takes arguments to `git diff`, so either of the
+above workflows work fine.  If all you want to do is upload a patch, you can use
+the upload.py provided by Rietveld with arguments like this:
+
+    upload.py --server server.com <args to "git diff">
+
+The first time you upload, it creates a new issue; for follow-ups on the same
+issue, you need to provide the issue number:
+
+    upload.py --server server.com --issue 1234 <args to "git diff">
+
+
+## git-cl to the rescue
+
+git-cl simplifies the above in the following ways:
+
+1. `git cl config` puts a persistent --server setting in your .git/config.
+2. The first time you upload an issue, the issue number is associated with the
+   current *branch*.  If you upload again, it will upload on the same issue.
+   (Note that this association is tied to a branch, not a commit, which means
+   you need a separate branch per review.)
+3. If your branch is _tracking_ (in the `git checkout --track` sense) another
+   one (like origin/master), calls to `git cl upload` will diff against that
+   branch by default.  (You can still pass arguments to `git diff` on the
+   command line, if necessary.)
+
+In the common case, this means that calling simply `git cl upload` will always
+upload the correct diff to the correct place.
+
+
+## Patch series
+
+The above is all you need to know for working on a single patch.
+
+Things get much more complicated when you have a series of commits that you want
+to get reviewed. Say your history looks like O--A--B--C. If you want to upload
+that as a single review, everything works just as above.
+
+But what if you upload each of A, B, and C as separate reviews? What if you
+then need to change A?
+
+1. One option is rewriting history: write a new commit A', then use
+   `git rebase -i` to insert that diff in as O--A--A'--B--C as well as squash
+   it. This is sometimes not possible if B and C have touched some lines
+   affected by A'.
+2. Another option, and the one espoused by software like topgit, is for you to
+   have separate branches for A, B, and C, and after writing A' you merge it
+   into each of those branches. (topgit automates this merging process.)  This
+   is also what is recommended by git-cl, which likes having different branch
+   identifiers to hang the issue number off of.  Your history ends up looking
+   like:
+
+       O---A---B---C
+            \   \   \
+             A'--B'--C'
+
+   Which is ugly, but it accurately tracks the real history of your work, can be
+   thrown away at the end by committing A+A' as a single `squash` commit.
+
+In practice, this comes up pretty rarely. Suggestions for better workflows are
+welcome.
+
+## Bash auto completion
+
+1. Ensure that your base git commands are autocompleted
+[doc](https://git-scm.com/book/en/v1/Git-Basics-Tips-and-Tricks).
+2. Add this to your .bashrc:
+
+        # The next line enables bash completion for git cl.
+        if [ -f "$HOME/bin/depot_tools/git_cl_completion.sh" ]; then
+          . "$HOME/bin/depot_tools/git_cl_completion.sh"
+        fi
+
+3. Profit.

depot_tools/cbuildbot

@@ -0,0 +1 @@
+support/chromite_wrapper

depot_tools/chrome_set_ver

@@ -0,0 +1 @@
+support/chromite_wrapper

depot_tools/cros

@@ -0,0 +1 @@
+support/chromite_wrapper

depot_tools/cros_sdk

@@ -0,0 +1 @@
+support/chromite_wrapper

depot_tools/man/src/.gitignore

@@ -0,0 +1,5 @@
+git
+asciidoc
+demo_repo
+ansi2html
+__*.txt