Skip to content

Commit

Permalink
Sync only to the upstream branch and do not cherry-pick
Browse files Browse the repository at this point in the history
Upstream sometimes uses merge commits which make it very difficult to
maintain a cherry-pick based sync workflow. This change modifies the way
syncing works so that it simply does a hard reset of the branch to the
filtered repository. This should be more foolproof, with the downside
that `main` is no longer up to date with upstream. Instead a new
`upstream` branch is always up-to-date.

Fixes #4861.
  • Loading branch information
mrobinson committed Dec 16, 2024
1 parent bd7704a commit c4bd5b4
Show file tree
Hide file tree
Showing 4 changed files with 27 additions and 41 deletions.
1 change: 0 additions & 1 deletion .github/sync/UPSTREAM_COMMIT

This file was deleted.

37 changes: 10 additions & 27 deletions .github/sync/sync.sh
Original file line number Diff line number Diff line change
Expand Up @@ -12,28 +12,17 @@
# repository with the filtered contents into a directory specified by the
# argument passed to this script. The filtered contents are determined
# by the configuration in `.github/sync/webrender.paths`.
# 3. Cherry-pick the new commits into the repository in the current working
# directory. The commits applied from the filtered repository are determined
# by choosing every commit after the hash found in the file
# `.github/sync/UPSTREAM_COMMIT`
# 3. Reset the `upstream` branch in the target repository to the new filtered
# version.
#
# Note that this script relies on the idea that filtering `gecko-dev` the same
# way more than once will result in the same commit hashes.
#
# If at some point, `webrender.paths` is modified and the commit hashes change,
# then a single manual filter will have to happen in order to translate the
# hash in the original filtered repository to the new one. The procedure for this
# is roughly:
#
# 1. Run `git-filter-repo` locally and note the new hash of the latest
# commit included from upstream.
# 2. Replace the contents `UPSTREAM_COMMIT` with that hash and commit
# it together with your changes to `webrender.paths`.
# way more than once will result in the same commit hashes, otherwise multiple
# copies of the version control history will be included in the repository.
#
# [1]: <https://github.com/mozilla/gecko-dev/> mirrored from
# <https://hg.mozilla.org/mozilla-central>
# [2]: <https://github.com/mozilla/gecko-dev/>
set -eu
set -eux

root_dir=$(pwd)
cache_dir=$root_dir/_cache
Expand Down Expand Up @@ -89,15 +78,9 @@ cd "$root_dir"
git remote add filtered-upstream "$filtered"
git fetch filtered-upstream

hash_file=".github/sync/UPSTREAM_COMMIT"
hash=`cat $hash_file`
number_of_commits=`git log $hash..filtered-upstream/master --pretty=oneline | wc -l`
step "Resetting 'upstream' branch to filtered repository HEAD"
git switch -c upstream
git reset --hard filtered-upstream/master

if [ $number_of_commits != '0' ]; then
step "Applying $number_of_commits new commits"
git -c user.email="$git_email" -c user.name="$git_name" cherry-pick $hash..filtered-upstream/master
git rev-parse filtered-upstream/master > "$hash_file"
git -c user.email="$git_email" -c user.name="$git_name" commit "$hash_file" -m "Syncing to upstream (`cat $hash_file`)"
else
step "No new commits. Doing nothing."
fi
step Pushing new 'upstream'
git push -f origin upstream
4 changes: 1 addition & 3 deletions .github/workflows/sync-upstream.yml
Original file line number Diff line number Diff line change
Expand Up @@ -19,6 +19,4 @@ jobs:
path: _cache/upstream
key: upstream
- name: Run synchronization script
run: ./.github/sync/sync.sh _filtered
- name: Pushing new `main`
run: git push origin main
run: ./.github/sync/sync.sh _filtered
26 changes: 16 additions & 10 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,17 +2,23 @@

[![Version](https://img.shields.io/crates/v/webrender.svg)](https://crates.io/crates/webrender)

WebRender is a GPU-based 2D rendering engine written in [Rust](https://www.rust-lang.org/). [Firefox](https://www.mozilla.org/firefox), the research web browser [Servo](https://github.com/servo/servo), and other GUI frameworks draw with it. It currently uses the OpenGL API internally.

Note that the canonical home for this code is in gfx/wr folder of the
mozilla-central repository at https://hg.mozilla.org/mozilla-central. The
Github repository at https://github.com/servo/webrender should be considered
WebRender is a GPU-based 2D rendering engine written in
[Rust](https://www.rust-lang.org/). [Firefox](https://www.mozilla.org/firefox),
the research web browser [Servo](https://github.com/servo/servo), and other GUI
frameworks draw with it. It currently uses the OpenGL API internally.

**Note that the upstream home for this code is in gfx/wr folder of the
mozilla-central repository at https://hg.mozilla.org/mozilla-central.** The
GitHub repository at https://github.com/servo/webrender should be considered
a downstream mirror, although it contains additional metadata (such as Github
wiki pages) that do not exist in mozilla-central. Pull requests against the
Github repository are still being accepted, although once reviewed, they will
be landed on mozilla-central first and then mirrored back. If you are familiar
with the mozilla-central contribution workflow, filing bugs in
[Bugzilla](https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Graphics%3A%20WebRender)
wiki pages) that do not exist in mozilla-central.

Generally speaking, improvements to WebRender should be submitted upstream
in Gecko, but those relevant to the Servo project or those unsuitable for
upstream may be accepted here.

If you are familiar with the mozilla-central contribution workflow, filing bugs
in [Bugzilla](https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Graphics%3A%20WebRender)
and submitting patches there would be preferred.

## Update as a Dependency
Expand Down

0 comments on commit c4bd5b4

Please sign in to comment.