Skip to content

Instantly share code, notes, and snippets.

@joaocgreis

joaocgreis/ChakraCore.md

Last active February 26, 2016 05:05
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save joaocgreis/869eccafda12f77473da to your computer and use it in GitHub Desktop.
Save joaocgreis/869eccafda12f77473da to your computer and use it in GitHub Desktop.
Download ZIP
Raw
ChakraCore.md

Evolving ChakraCore on Node.js with rebases instead of merges

The Node.js master branch is constantly evolving. The chakracore-master branch is also evolving, both by fixing breaking changes from master and by landing new things, making it better. The goal of the chakracore-master branch is to produce a set of easy to review commits, that can be used to open a pull request against master.

For the master branch in a given moment (tagged master-DATE), we can create a chakracore-DATE branch that represents the state of ChakraCore on Node for that revision of master. When updating master, the dated chakracore branch should be rebased against the new dated master branch, creating a new dated chakracore branch using a pull request. Updates to ChakraCore and ChakraShim should either replace the commits of the original versions, or, if the update should be separated, have a different pull request. A chakracore-master branch can be created pointing to the most recent version of ChakraCore on Node, being force pushed only when the updates from master land.

Pull requests should be open against the chakracore-master branch. This will flood the pull request with old commits when the branch is force pushed, but allows for the pull request to be updated without opening a new one.

We should decide if changes land in chakracore-master or in the most recent dated chakracore branch. Either way, when updating master, all changes should be included in the new dated chakracore branch.

Pull requests can be fixups to previous commits, we should decide if fixups are applied when landing (force-pushing the target branch) or only when updating master (leveraging the rebase).

How to prepare an update from master

Preparing the update

(Assuming use of Git Bash)

TODAY=$(date +%Y%m%d)

git reset --hard
git clean -fdx
git checkout master

git tag master-$TODAY
git branch chakracore-$TODAY

git checkout -b chakracore-${TODAY}-staging chakracore-master
git rebase chakracore-$TODAY # solve conflicts

# Apply updates, squash or fixup
git rebase -i master-$TODAY

Create a pull request

  • Base: chakracore-$TODAY
  • Head: chakracore-${TODAY}-staging

Landing the update

Make sure all landed pull requests are rebased and included in the new branch.

git checkout chakracore-$TODAY
git merge --ff-only chakracore-${TODAY}-staging
git branch -d chakracore-${TODAY}-staging
git branch -f chakracore-master

Walkthrough to current status

This shows how rebasing would have applied to the previous updates.

The resulting changes are easy to review: https://github.com/janeasystems/node-chakracore-rebased/compare/master...chakracore-master .

git init
git pull https://github.com/nodejs/node.git
git fetch -n https://github.com/nodejs/node.git +refs/pull/4765/head:refs/heads/pull/4765
git fetch -n https://github.com/nodejs/node-chakracore.git +refs/pull/25/head:refs/heads/pull/25 +refs/pull/30/head:refs/heads/pull/30

The original PR, nodejs/node#4765

git tag master-20151230 6efa031
git branch chakracore-20151230 6efa031
git checkout -b chakracore-20151230-staging 6efa031
git cherry-pick 6efa031..42bc284 # As if the changes were done in this branch
# Would open PR from chakracore-20151230-staging to chakracore-20151230, land with:
git checkout chakracore-20151230
git merge --ff-only chakracore-20151230-staging
git branch -d chakracore-20151230-staging
git branch chakracore-master

The first update PR, nodejs/node-chakracore#25

git tag master-20160203 7406cd3
git branch chakracore-20160203 7406cd3
git checkout -b chakracore-20160203-staging chakracore-master
git rebase chakracore-20160203
# The conflicts are the same as by merging, and since they are solved in the PR we can shortcut:
git checkout 1992a83 README.md vcbuild.bat
git rebase --continue
git checkout 1992a83 test/parallel/test-buffer-slow.js test/parallel/test-util-inspect.js test/parallel/test-util-log.js
git rebase --continue
# Then apply the 3 new commits
git cherry-pick 3062354..1992a83
# These 3 new commits should be squashed with the respective original commits to simplify the changes
# (the chakrashim commit needs to be split because of gyp)
git rebase -i master-20160203
# Would open PR from chakracore-20160203-staging to chakracore-20160203, land with:
git checkout chakracore-20160203
git merge --ff-only chakracore-20160203-staging
git branch -d chakracore-20160203-staging
git branch -f chakracore-master

The second update PR, nodejs/node-chakracore#30

git tag master-20160222 2678e14
git branch chakracore-20160222 2678e14
git checkout -b chakracore-20160222-staging chakracore-master
git rebase chakracore-20160222
# The conflicts are solved in the PR, we can shortcut:
git checkout 785b5f6 README.md
git rebase --continue
git checkout 785b5f6 lib/repl.js
git rebase --continue
git checkout 785b5f6 test/parallel/test-debug-brk.js test/parallel/test-debug-no-context.js
git rebase --continue
# Then apply the 3 new commits
git cherry-pick e3d86e2..785b5f6
# These 3 new commits should be squashed with the respective original commits to simplify the changes
git rebase -i master-20160222
# Would open PR from chakracore-20160222-staging to chakracore-20160222, land with:
git checkout chakracore-20160222
git merge --ff-only chakracore-20160222-staging
git branch -d chakracore-20160222-staging
git branch -f chakracore-master
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment