Change all references to master branch to trunk

.circleci/config.yml

@@ -758,7 +758,7 @@ jobs:
 
             # Build all artifacts only when project config changes.
             # Otherwise only build application executable required for end-to-end testing.
-            ! git diff --name-only origin/master...HEAD | grep -E -q 'desktop/package.json|desktop/yarn.lock' && ELECTRON_BUILDER_ARGS='-c.mac.target=dir'
+            ! git diff --name-only origin/trunk...HEAD | grep -E -q 'desktop/package.json|desktop/yarn.lock' && ELECTRON_BUILDER_ARGS='-c.mac.target=dir'
 
             ELECTRON_BUILDER_ARGS=$ELECTRON_BUILDER_ARGS yarn run build-desktop:app
       - run:
@@ -819,7 +819,7 @@ jobs:
 
             # Build all artifacts only when project config changes.
             # Otherwise only build application executable required for end-to-end testing.
-            ! git diff --name-only origin/master...HEAD | grep -E -q 'desktop/package.json|desktop/yarn.lock' && ELECTRON_BUILDER_ARGS='-c.linux.target=dir'
+            ! git diff --name-only origin/trunk...HEAD | grep -E -q 'desktop/package.json|desktop/yarn.lock' && ELECTRON_BUILDER_ARGS='-c.linux.target=dir'
 
             ELECTRON_BUILDER_ARGS=$ELECTRON_BUILDER_ARGS yarn run build-desktop:app
       - run:
@@ -905,7 +905,7 @@ jobs:
 
             # Build all artifacts only when project config changes.
             # Otherwise only build application executable required for end-to-end testing.
-            If ( -Not $(git diff --name-only origin/master...HEAD | Select-String -Pattern desktop/package.json,desktop/yarn.lock) ) { $env:ARG2='-c.win.target=dir' }
+            If ( -Not $(git diff --name-only origin/trunk...HEAD | Select-String -Pattern desktop/package.json,desktop/yarn.lock) ) { $env:ARG2='-c.win.target=dir' }
 
 
             make -f desktop/Makefile package ELECTRON_BUILDER_ARGS=$($env:ARG1,$env:ARG2 -join " ")
@@ -976,7 +976,7 @@ workflows:
       - prime-calypso-live:
           filters:
             branches:
-              ignore: master
+              ignore: trunk
       - build-notifications:
           requires:
             - setup
@@ -1011,8 +1011,8 @@ workflows:
           filters:
             branches:
               ignore:
-                # Do not spin up calypso.live for `master`
-                - master
+                # Do not spin up calypso.live for `trunk`
+                - trunk
                 # Do not spin up calypso.live for fork pull requests. Calypso.live will not build them.
                 - /pull\/[0-9]+/
       #      - test-e2e-canary:
@@ -1104,7 +1104,7 @@ workflows:
           filters:
             branches:
               only:
-                - master
+                - trunk
 
   e2e-full-suite-scheduled:
     jobs:
@@ -1117,7 +1117,7 @@ workflows:
           cron: '0 3,15 * * *'
           filters:
             branches:
-              only: master
+              only: trunk
 
   e2e-canary-scheduled:
     jobs:
@@ -1141,7 +1141,7 @@ workflows:
           cron: '0 12 * * *'
           filters:
             branches:
-              only: master
+              only: trunk
 
   e2e-jetpack-be-scheduled:
     jobs:
@@ -1159,7 +1159,7 @@ workflows:
           cron: '0 7 * * *'
           filters:
             branches:
-              only: master
+              only: trunk
 
   # Temporarily disabling these scheduled test runs
   #  e2e-jetpack-scheduled:
@@ -1178,7 +1178,7 @@ workflows:
   #        cron: "0 1,13 * * *"
   #        filters:
   #          branches:
-  #            only: master
+  #            only: trunk
 
   e2e-canary-i18n-monthly:
     jobs:
@@ -1191,13 +1191,13 @@ workflows:
           test-flags: '-i'
           filters:
             branches:
-              only: master
+              only: trunk
     triggers:
       - schedule:
           cron: '40 15 19 * *'
           filters:
             branches:
-              only: master
+              only: trunk
 
   e2e-canary-i18n-nightly:
     jobs:
@@ -1210,11 +1210,11 @@ workflows:
           test-flags: '-I'
           filters:
             branches:
-              only: master
+              only: trunk
     triggers:
       - schedule:
           cron: '46 4 * * *'
           filters:
             branches:
-              only: master
+              only: trunk
 # vi: sts=2 ts=2 sw=2 et

bin/eslint-branch.js

@@ -13,7 +13,7 @@ const eslintBin = path.join( '.', 'node_modules', '.bin', 'eslint' );
 
 const branchName = child_process.execSync( 'git rev-parse --abbrev-ref HEAD' ).toString().trim();
 const rev = child_process
-	.execSync( 'git merge-base ' + branchName + ' master' )
+	.execSync( 'git merge-base ' + branchName + ' trunk' )
 	.toString()
 	.trim();
 const files = child_process

bin/get-circle-artifact-url.js

@@ -17,10 +17,10 @@ async function getCircleArtifactUrl( pathMatchRegex ) {
 		process.exit( 1 );
 	}
 	try {
-		// Fetch recent successful master builds
+		// Fetch recent successful trunk builds
 		const builds = await httpsGetJsonPromise( {
 			...baseOptions,
-			path: `${ basePath }/tree/master?filter=successful&limit=${ maxBuilds }`,
+			path: `${ basePath }/tree/trunk?filter=successful&limit=${ maxBuilds }`,
 		} );
 
 		const buildNumbersWithArtifacts = builds

bin/get-circle-string-artifact-url

@@ -1,6 +1,6 @@
 #!/usr/bin/env node
 
-// This script will return a url of the calypso-strings.pot file generated in our latest master build.
+// This script will return a url of the calypso-strings.pot file generated in our latest trunk build.
 // eg: node bin/get-circle-string-artifact-url | xargs curl
 
 const getCircleArtifactUrl = require( './get-circle-artifact-url' );

bin/pre-push-hook.js

@@ -11,8 +11,8 @@ console.log(
 
 const currentBranch = execSync( 'git rev-parse --abbrev-ref HEAD' ).toString().trim();
 
-if ( 'master' === currentBranch ) {
-	if ( ! readline.keyInYN( "You're about to push !!![ master ]!!!, is that what you intended?" ) ) {
+if ( 'trunk' === currentBranch ) {
+	if ( ! readline.keyInYN( "You're about to push !!![ trunk ]!!!, is that what you intended?" ) ) {
 		process.exit( 1 );
 	}
 }

client/components/environment-badge/index.jsx

@@ -30,7 +30,7 @@ export function TestHelper() {
 }
 
 export function Branch( { branchName, commitChecksum } ) {
-	return branchName === 'master' ? null : (
+	return branchName === 'trunk' ? null : (
 		/* eslint-disable wpcalypso/jsx-classname-namespace */
 		<span className="environment branch-name" title={ 'Commit ' + commitChecksum }>
 			{ branchName }

client/components/head/index.jsx

@@ -38,7 +38,7 @@ const Head = ( { title = 'WordPress.com', children, branchName, inlineScriptNonc
 
 			<link rel="profile" href="http://gmpg.org/xfn/11" />
 
-			{ ! branchName || 'master' === branchName ? (
+			{ ! branchName || 'trunk' === branchName ? (
 				<link rel="manifest" href="/calypso/manifest.json" />
 			) : (
 				<link

client/components/readme-viewer/index.jsx

@@ -55,7 +55,7 @@ export default class ReadmeViewer extends Component {
 		const editLink = (
 			<a
 				className="readme-viewer__doc-edit-link devdocs__doc-edit-link"
-				href={ `https://github.com/Automattic/wp-calypso/edit/master${ readmeFilePath }` }
+				href={ `https://github.com/Automattic/wp-calypso/edit/trunk${ readmeFilePath }` }
 			>
 				Improve this document on GitHub
 			</a>

client/devdocs/doc.jsx

@@ -96,7 +96,7 @@ export default class extends React.Component {
 
 	renderBody() {
 		const editURL = encodeURI(
-			'https://github.com/Automattic/wp-calypso/edit/master/' + this.props.path
+			'https://github.com/Automattic/wp-calypso/edit/trunk/' + this.props.path
 		);
 		const { body, error } = this.state;
 

client/layout/guided-tours/docs/TUTORIAL.md

@@ -230,7 +230,7 @@ A few notes:
 - The first step of a tour needs to have a name of `init` to be recognizable as the first step by the framework.
 - The `target` is the DOM element the step should be "glued" to or will point at. There are two ways to do that: either the element has a `data-tip-target` attribute, and we pass that name, or we pass a CSS selector that selects that element (cf. method `targetForSlug`). In this case, it's a `data-tip-target`.
 - The `scrollContainer` tells the framework which container it should attempt to scroll in case the `target` isn't visible. In this case, the framework will attempt to scroll the sidebar until the site preview button is in view.
-- `translate` calls: we'd add those only after multiple iterations over the copy. Once you merge something with a `translate` call into `master`, the strings will be translated -- and we don't want to waste anyone's time with translating strings that will still change a few times.
+- `translate` calls: we'd add those only after multiple iterations over the copy. Once you merge something with a `translate` call into `trunk`, the strings will be translated -- and we don't want to waste anyone's time with translating strings that will still change a few times.
 - The `Continue` steps attributes basically say: when the user `click`s the `target`, proceed to the step called `close-preview` (the next step, below). The `hidden` attribute tells the framework to not add an explanatory text below the step.
 - The `ButtonRow` with the `Quit` button doesn't really look nice, but it's important to provide a way for the user to get out of the tour. The framework will quit a tour if it believes that the user is trying to navigate away from it, but in this case we thought an explicit way to quit would be good to provide.
 

client/server/pwa/manifest.js

@@ -72,7 +72,7 @@ const buildManifest = ( { branchName } ) => {
 	// then this can be safely removed.
 	const environmentUrlOptions = { source: 'pwa' };
 
-	if ( branchName && 'master' !== branchName ) {
+	if ( branchName && 'trunk' !== branchName ) {
 		environmentUrlOptions.branch = branchName;
 	}
 

docs/CONTRIBUTING.md

@@ -86,13 +86,13 @@ Once you know what the first small piece of your feature will be, follow this ge
     - Don’t be afraid to change, [squash](http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html), and rearrange commits or to force push - `git push -f origin fix/something-broken`. Keep in mind, however, that if other people are committing on the same branch then you can mess up their history. You are perfectly safe if you are the only one pushing commits to that branch.
     - Squash minor commits such as typo fixes or [fixes to previous commits](http://fle.github.io/git-tip-keep-your-branch-clean-with-fixup-and-autosquash.html) in the pull request.
 4. If you end up needing more than a few commits, consider splitting the pull request into separate components. Discuss in the new pull request and in the comments why the branch was broken apart and any changes that may have taken place that necessitated the split. Our goal is to catch early in the review process those pull requests that attempt to do too much.
-5. When you feel that you are ready for a formal review or for merging into `master` make sure you check this list and our [merge checklist](../docs/merge-checklist.md).
-    - Make sure your branch merges cleanly and consider rebasing against `master` to keep the branch history short and clean.
+5. When you feel that you are ready for a formal review or for merging into `trunk` make sure you check this list and our [merge checklist](../docs/merge-checklist.md).
+    - Make sure your branch merges cleanly and consider rebasing against `trunk` to keep the branch history short and clean.
     - If there are visual changes, add before and after screenshots in the pull request comments.
     - Add unit tests, or at a minimum, provide helpful instructions for the reviewer so they can test your changes. This will help speed up the review process.
     - Ensure that your commit messages are [meaningful](http://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message).
 6. Mention that the PR is ready for review or if you have write access remove the **<span class="label status-in-progress">[Status] In Progress</span>** label from the pull request and add the **<span class="label status-needs-review">[Status] Needs Review</span>** label - someone will provide feedback on the latest unreviewed changes. The reviewer will also mark the pull request as **<span class="label status-needs-author-reply">[Status] Needs Author Reply</span>** if they think you need to change anything.
-7. If you get a 👍, 💥, 🚢, <img src="https://github.githubassets.com/images/icons/emoji/shipit.png" class="emoji" />, or a LGTM and the status has been changed to **<span class="label status-ready-to-merge">[Status] Ready to Merge</span>** – this is great – the pull request is ready to be merged into `master`.
+7. If you get a 👍, 💥, 🚢, <img src="https://github.githubassets.com/images/icons/emoji/shipit.png" class="emoji" />, or a LGTM and the status has been changed to **<span class="label status-ready-to-merge">[Status] Ready to Merge</span>** – this is great – the pull request is ready to be merged into `trunk`.
 
 Whether somebody is reviewing your code or you are reviewing somebody else’s code, [a positive mindset towards code reviews](https://medium.com/medium-eng/the-code-review-mindset-3280a4af0a89) helps a ton. We’re building something together that is greater than the sum of its parts.
 

docs/data-persistence.md

@@ -136,7 +136,7 @@ from changing data shapes, as described below.
 As time passes, the shape of our data will change very drastically in our Redux store and in each subtree. If we now
 persist state, we run into the issue of our persisted data shape no longer matching what the Redux store expects.
 
-As a developer, this case is extremely easy to hit. If Redux persistence is enabled and we are running master, first
+As a developer, this case is extremely easy to hit. If Redux persistence is enabled and we are running trunk, first
 allow  state to be persisted to the browser and then switch to another git branch that contains minor refactors for an
 existing sub-tree. What happens when a selector reaches for a data property that doesn't exist or has been renamed?
 Errors!

docs/git-workflow.md

@@ -4,7 +4,7 @@ Git Workflow
 [Branch Naming Scheme](#branch-naming-scheme)
 --------------------
 
-All changes should be developed in a new branch created from the `master` branch.
+All changes should be developed in a new branch created from the `trunk` branch.
 
 Branches use the following naming conventions:
 
@@ -13,7 +13,7 @@ Branches use the following naming conventions:
 * `fix/{something}` -- When you are fixing something broken in a feature
 * `try/{something}` -- When you are trying out an idea and want feedback
 
-For example, you can run: `git checkout master` and then `git checkout -b fix/whatsits` to create a new `fix/whatsits` branch off of `origin/master`.
+For example, you can run: `git checkout trunk` and then `git checkout -b fix/whatsits` to create a new `fix/whatsits` branch off of `origin/trunk`.
 
 **warning**: Using multiple slashes causes problems with Calypso Live testing. See: [Git branches with multiple slashes](https://stackoverflow.com/questions/2527355/using-the-slash-character-in-git-branch-name). Stick to a single slash.
 
@@ -27,9 +27,9 @@ For larger features, keeping branches small requires hiding work-in-progress (WI
 Keeping Your Branch Up To Date
 ------------------------------------------------
 
-While it is tempting to merge from `master` into your branch frequently, this leads to a messy history because each merge creates a merge commit. When working by yourself, it is best to use `git pull --rebase master`, but if you're pushing to a shared repo, it is best to not do any merging or rebasing until the feature is ready for final testing, and then do a [rebase](https://github.com/edx/edx-platform/wiki/How-to-Rebase-a-Pull-Request) at the very end. This is one reason why it is important to open pull requests whenever you have working code.
+While it is tempting to merge from `trunk` into your branch frequently, this leads to a messy history because each merge creates a merge commit. When working by yourself, it is best to use `git pull --rebase trunk`, but if you're pushing to a shared repo, it is best to not do any merging or rebasing until the feature is ready for final testing, and then do a [rebase](https://github.com/edx/edx-platform/wiki/How-to-Rebase-a-Pull-Request) at the very end. This is one reason why it is important to open pull requests whenever you have working code.
 
-If you have a Pull Request branch that cannot be merged into `master` due to a conflict (this can happen for long-running Pull Request discussions), it's still best to rebase the branch (rather than merge) and resolve any conflicts on your local copy. 
+If you have a Pull Request branch that cannot be merged into `trunk` due to a conflict (this can happen for long-running Pull Request discussions), it's still best to rebase the branch (rather than merge) and resolve any conflicts on your local copy. 
 
 Once you have resolved any conflicts locally you can update the Pull Request with `git push --force-with-lease` (note: we prefer using `--force-with-lease` over `--force` to help protect remote commits). 
 

docs/guide/hello-world.md

@@ -30,7 +30,7 @@ First thing is to enable your new feature in Calypso. We'll do that by opening `
 "hello-world": true
 ```
 
-Feature flags are a great way to enable/disable certain features in specific environments. For example, we can merge our "Hello, World!" code in `master,` but hide it behind a feature flag. We have [more documentation on feature flags](../../client/config).
+Feature flags are a great way to enable/disable certain features in specific environments. For example, we can merge our "Hello, World!" code in `trunk,` but hide it behind a feature flag. We have [more documentation on feature flags](../../client/config).
 
 ### 2. Set up folder structure
 

docs/monorepo.md

@@ -167,16 +167,16 @@ For all packages that you want to publish, make sure that their `package.json` v
 
 Make sure that the `CHANGELOG.md` document contains up-to-date information, with the `next` heading replaced with the version number that you are about to publish.
 
-Create PRs with the necessary changes and merge them to `master` before publishing. Lerna will add a `gitHead` field to each published package's `package.json`. That field contains the hash of the Git commit that the package was published from. It's better if this commit hash is a permanent one from the `master` branch, rather than an ephemeral commit from a local branch.
+Create PRs with the necessary changes and merge them to `trunk` before publishing. Lerna will add a `gitHead` field to each published package's `package.json`. That field contains the hash of the Git commit that the package was published from. It's better if this commit hash is a permanent one from the `trunk` branch, rather than an ephemeral commit from a local branch.
 
-### Checkout the latest master locally and build the packages
+### Checkout the latest trunk locally and build the packages
 
-Always publish from the latest `master` branch, so that the package contents come from a verified source that everyone has access to. It's too easy to publish a NPM package from a local branch, or even uncommitted local modifications that are invisible to anyone but you.
+Always publish from the latest `trunk` branch, so that the package contents come from a verified source that everyone has access to. It's too easy to publish a NPM package from a local branch, or even uncommitted local modifications that are invisible to anyone but you.
 
 Build the `dist/` directories (the transpiled package content that will be published) from scratch.
 
 ```
-git checkout master
+git checkout trunk
 git pull
 git status (should be clean!)
 yarn run distclean

packages/eslint-config-wpcalypso/README.md

@@ -32,9 +32,9 @@ Refer to the [ESLint documentation on Shareable Configs](http://eslint.org/docs/
 
 ## Suggesting Changes
 
-Want to suggest a change to our style guide? [Edit the JavaScript Coding Guidelines on the Automattic/wp-calypso repository](https://github.com/Automattic/wp-calypso/edit/master/docs/coding-guidelines/javascript.md) and submit a pull request.
+Want to suggest a change to our style guide? [Edit the JavaScript Coding Guidelines on the Automattic/wp-calypso repository](https://github.com/Automattic/wp-calypso/edit/trunk/docs/coding-guidelines/javascript.md) and submit a pull request.
 
-Want to revise the ESLint rules used here? [Edit the `index.js` file](https://github.com/Automattic/eslint-config-wpcalypso/edit/master/index.js) and submit a pull request.
+Want to revise the ESLint rules used here? [Edit the `index.js` file](https://github.com/Automattic/eslint-config-wpcalypso/edit/trunk/index.js) and submit a pull request.
 
 ## License