Staging repository for element tracking feature prototype.
Shell
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
OpenSource @ 9e02a69
patches/scry
scripts
.gitignore
.gitmodules
README.md

README.md

This is a staging repository for work on the element tracking research prototype, codenamed Scry. It's used to keep a fairly clean set of patches on top of WebKit trunk, allowing close tracking of upstream progress.

The repository contains a patch series under version control, as well as a WebKit repository submodule at a particular version to which the patches should be applied. This allows patches to be based on a specific commit of WebKit, and to be updated as that base commit catches up to the master branch of the WebKit git repository.


Getting

git clone git://github.com/burg/scry-staging.git

Then follow the steps below for updating.

Updating

Pull new commits to the staging repository, then pull commits to the submodule. The initial update will take a long time, because it needs to download the entire WebKit git repository (over 5GB in size).

git pull
git submodule update --init --recursive
git submodule update --recursive
scripts/import-patches

Now you should be able to go into the OpenSource directory and build WebKit as normal. More details on building WebKit itself.

Importing/Applying Patches

From within the WebKit submodule working copy or within the staging working copy, you can run the following command to export any commits between the merge-base and head of the submodule.

scripts/import-patches

Note: this script requires the working copy to be clean, and will abort if there are any patches already applied to the WebKit submodule (i.e., HEAD is not merge-base).

Exporting Patches

From within the WebKit submodule working copy or within the staging working copy, you can run the following command to export any commits between the merge-base and head of the submodule.

scripts/export-patches

Note: this script requires the working copy to be clean, and does not reset the submodule's head to point to the merge-base commit. This is intentional, so that exporting and committing patches does not necessarily clobber the submodule working copy's build state.

Updating the WebKit base commit

To update the merge-base commit of the submodule---say, you want to incorporate new WebKit commit changes---you must rebase patches in the submodule and update the submodule commit hash to point to the new merge-base commit. This is done automatically by the export-patches script.

To update to a newer WebKit, do the following from the submodule:

  1. (Commit any outstanding changes)
  2. git pull --rebase
  3. ../scripts/export-patches
  4. (Go to staging repository; make commit)

It is recommended that you update the base commit by first applying all patches and using git rebase rather than trying to apply patches to a new base commit using git am or import-patches. The former lets you use the familiar tools for rebasing, while the latter requires digging into the import script's implementation if patches fail to apply.

Repository Structure

    OpenSource/    # A submodule that points to the official WebKit git mirror.
                   # (git://git.webkit.org/WebKit.git)

    patches/       # Base directory for all patches.
        scry/    # Contains element tracking feature patches.