diff options
| author | Stefan van der Walt <stefanv@berkeley.edu> | 2021-03-04 07:11:41 -0800 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2021-03-04 09:11:41 -0600 |
| commit | 954605ec08ad833899ffb956395f2d70f8eea2df (patch) | |
| tree | a728df2ab2d8c29e8a36e98cd4a97581e87460ea | |
| parent | 7134dcfe5f43146ffd1ba8d9c58504ec7146ea3f (diff) | |
| download | numpy-954605ec08ad833899ffb956395f2d70f8eea2df.tar.gz | |
MAINT: Update master to main after branch rename (gh-18544)
* Upload docs to main branch of neps/devdocs
* Update `master` to `main` to be consistent with current state of renaming
* Remove badges from README
* Replace remaining instances of `master` with `main`
* Add back logo
* Fix CircleCI branch checks
* Fix GA branch name
* master->main in issue templates.
* master->main for 2 links to numpy archive.
* Change master to main in NEP 23
Co-authored-by: Ross Barnowski <rossbar@berkeley.edu>
36 files changed, 97 insertions, 104 deletions
diff --git a/.circleci/config.yml b/.circleci/config.yml index ea50ca84f..6f4a32513 100644 --- a/.circleci/config.yml +++ b/.circleci/config.yml @@ -91,7 +91,7 @@ jobs: - run: name: deploy devdocs command: | - if [ "${CIRCLE_BRANCH}" == "master" ]; then + if [ "${CIRCLE_BRANCH}" == "main" ]; then touch doc/build/html/.nojekyll ./tools/ci/push_docs_to_repo.py doc/build/html \ @@ -101,7 +101,7 @@ jobs: --message "Docs build of $CIRCLE_SHA1" \ --force else - echo "Not on the master branch; skipping deployment" + echo "Not on the main branch; skipping deployment" fi - add_ssh_keys: @@ -120,7 +120,7 @@ jobs: - run: name: deploy neps command: | - if [ "${CIRCLE_BRANCH}" == "master" ]; then + if [ "${CIRCLE_BRANCH}" == "main" ]; then touch doc/neps/_build/html/.nojekyll ./tools/ci/push_docs_to_repo.py doc/neps/_build/html \ @@ -130,5 +130,5 @@ jobs: --message "Docs build of $CIRCLE_SHA1" \ --force else - echo "Not on the master branch; skipping deployment" + echo "Not on the main branch; skipping deployment" fi diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md index da5990956..8f16950f7 100644 --- a/.github/CONTRIBUTING.md +++ b/.github/CONTRIBUTING.md @@ -8,7 +8,7 @@ also include a brief, self-contained code example that demonstrates the problem. If you are reporting a segfault please include a GDB traceback, which you can generate by following -[these instructions.](https://github.com/numpy/numpy/blob/master/doc/source/dev/development_environment.rst#debugging) +[these instructions.](https://github.com/numpy/numpy/blob/main/doc/source/dev/development_environment.rst#debugging) ## Contributing code diff --git a/.github/ISSUE_TEMPLATE/bug-report.md b/.github/ISSUE_TEMPLATE/bug-report.md index 78ffc1063..6da1f7370 100644 --- a/.github/ISSUE_TEMPLATE/bug-report.md +++ b/.github/ISSUE_TEMPLATE/bug-report.md @@ -20,7 +20,7 @@ import numpy as np <!-- If you are reporting a segfault please include a GDB traceback, which you can generate by following -https://github.com/numpy/numpy/blob/master/doc/source/dev/development_environment.rst#debugging --> +https://github.com/numpy/numpy/blob/main/doc/source/dev/development_environment.rst#debugging --> <!-- Full error message, if any (starting from line Traceback: ...) --> diff --git a/.github/ISSUE_TEMPLATE/feature-request.md b/.github/ISSUE_TEMPLATE/feature-request.md index 00c6f59c5..68872ec06 100644 --- a/.github/ISSUE_TEMPLATE/feature-request.md +++ b/.github/ISSUE_TEMPLATE/feature-request.md @@ -12,5 +12,5 @@ post your idea on the [numpy-discussion mailing list] (https://mail.python.org/mailman/listinfo/numpy-discussion) to explain your reasoning in addition to opening an issue or pull request. You can also check out our [Contributor Guide] -(https://github.com/numpy/numpy/blob/master/doc/source/dev/index.rst) if you +(https://github.com/numpy/numpy/blob/main/doc/source/dev/index.rst) if you need more information. --> diff --git a/.github/ISSUE_TEMPLATE/post-install.md b/.github/ISSUE_TEMPLATE/post-install.md index c0ec7896a..11b91384c 100644 --- a/.github/ISSUE_TEMPLATE/post-install.md +++ b/.github/ISSUE_TEMPLATE/post-install.md @@ -15,7 +15,7 @@ labels: 32 - Installation <!-- If you are reporting a segfault please include a GDB traceback, which you can generate by following -https://github.com/numpy/numpy/blob/master/doc/source/dev/development_environment.rst#debugging --> +https://github.com/numpy/numpy/blob/main/doc/source/dev/development_environment.rst#debugging --> <!-- Full error message, if any (starting from line Traceback: ...) --> diff --git a/.github/workflows/build_test.yml b/.github/workflows/build_test.yml index 5366fe75e..2f792339b 100644 --- a/.github/workflows/build_test.yml +++ b/.github/workflows/build_test.yml @@ -3,11 +3,11 @@ name: Build_Test on: push: branches: - - master + - main - maintenance/** pull_request: branches: - - master + - main - maintenance/** defaults: @@ -1,12 +1,5 @@ # <img alt="NumPy" src="/branding/logo/primary/numpylogo.svg" height="60"> -[]( - https://travis-ci.com/github/numpy/numpy) -[]( - https://dev.azure.com/numpy/numpy/_build/latest?definitionId=5) -[]( - https://codecov.io/gh/numpy/numpy) - NumPy is the fundamental package needed for scientific computing with Python. - **Website:** https://www.numpy.org diff --git a/benchmarks/README.rst b/benchmarks/README.rst index f56c25339..2700e95e7 100644 --- a/benchmarks/README.rst +++ b/benchmarks/README.rst @@ -50,7 +50,7 @@ Compare change in benchmark results to another version/commit/branch:: python runtests.py --bench-compare v1.6.2 bench_core python runtests.py --bench-compare 8bf4e9b bench_core - python runtests.py --bench-compare master bench_core + python runtests.py --bench-compare main bench_core All of the commands above display the results in plain text in the console, and the results are not saved for comparison with diff --git a/doc/DISTUTILS.rst.txt b/doc/DISTUTILS.rst.txt index c58a423c0..539a3b9c1 100644 --- a/doc/DISTUTILS.rst.txt +++ b/doc/DISTUTILS.rst.txt @@ -472,7 +472,7 @@ by these modules during the build process are ready to be compiled. This form of generic typing is also supported for C header files (preprocessed to produce ``.h`` files). -.. _conv_template.py: https://github.com/numpy/numpy/blob/master/numpy/distutils/conv_template.py +.. _conv_template.py: https://github.com/numpy/numpy/blob/main/numpy/distutils/conv_template.py Useful functions in ``numpy.distutils.misc_util`` ------------------------------------------------- diff --git a/doc/HOWTO_RELEASE.rst.txt b/doc/HOWTO_RELEASE.rst.txt index 9dbee320c..c64a36691 100644 --- a/doc/HOWTO_RELEASE.rst.txt +++ b/doc/HOWTO_RELEASE.rst.txt @@ -18,7 +18,7 @@ Source tree NumPy Docs ---------- -- https://github.com/numpy/numpy/blob/master/doc/HOWTO_RELEASE.rst.txt +- https://github.com/numpy/numpy/blob/main/doc/HOWTO_RELEASE.rst.txt SciPy.org wiki @@ -35,7 +35,7 @@ Supported platforms and versions ================================ :ref:`NEP 29 <NEP29>` outlines which Python versions are supported; For the first half of 2020, this will be Python >= 3.6. We test -NumPy against all these versions every time we merge code to master. Binary +NumPy against all these versions every time we merge code to main. Binary installers may be available for a subset of these versions (see below). OS X @@ -185,7 +185,7 @@ A typical release schedule is one beta, two release candidates and a final release. It's best to discuss the timing on the mailing list first, in order for people to get their commits in on time, get doc wiki edits merged, etc. After a date is set, create a new maintenance/x.y.z branch, add new empty -release notes for the next version in the master branch and update the Trac +release notes for the next version in the main branch and update the Trac Milestones. @@ -336,8 +336,8 @@ to public keyservers, with a command such as:: gpg --send-keys <yourkeyid> -Update the version of the master branch ---------------------------------------- +Update the version of the main branch +------------------------------------- Increment the release number in setup.py. Release candidates should have "rc1" (or "rc2", "rcN") appended to the X.Y.Z format. @@ -492,5 +492,5 @@ After the final release is announced, a few administrative tasks are left to be done: - Forward port changes in the release branch to release notes and release - scripts, if any, to master branch. + scripts, if any, to main branch. - Update the Milestones in Trac. diff --git a/doc/RELEASE_WALKTHROUGH.rst.txt b/doc/RELEASE_WALKTHROUGH.rst.txt index 1d3f54edf..4fbc7af1c 100644 --- a/doc/RELEASE_WALKTHROUGH.rst.txt +++ b/doc/RELEASE_WALKTHROUGH.rst.txt @@ -29,7 +29,7 @@ appended to ``doc/release/1.19.0-notes.rst`` for patch release, though not for new releases like ``1.19.0``, as the changelogs for ``*.0`` releases tend to be excessively long. The ``doc/source/release.rst`` file should also be updated with a link to the new release notes. These changes should be committed to the -maintenance branch, and later will be forward ported to master. The changelog +maintenance branch, and later will be forward ported to main. The changelog should be reviewed for name duplicates or short names and the ``.mailmap`` file updated if needed. @@ -292,7 +292,7 @@ python-announce-list is BCC so that replies will not be sent to that list. Post-Release Tasks ------------------ -Checkout master and forward port the documentation changes:: +Checkout main and forward port the documentation changes:: $ git checkout -b post-1.19.0-release-update $ git checkout maintenance/1.19.x doc/source/release/1.19.0-notes.rst @@ -301,7 +301,7 @@ Checkout master and forward port the documentation changes:: $ gvim doc/source/release.rst # Add link to new notes $ git add doc/changelog/1.19.0-changelog.rst doc/source/release/1.19.0-notes.rst $ git status # check status before commit - $ git commit -a -m"REL: Update master after 1.19.0 release." + $ git commit -a -m"REL: Update main after 1.19.0 release." $ git push origin HEAD Go to github and make a PR. diff --git a/doc/TESTS.rst.txt b/doc/TESTS.rst.txt index 0cb24684f..21cc08673 100644 --- a/doc/TESTS.rst.txt +++ b/doc/TESTS.rst.txt @@ -278,7 +278,7 @@ minor variations, it can be helpful to create a base class containing all the common tests, and then create a subclass for each variation. Several examples of this technique exist in NumPy; below are excerpts from one in `numpy/linalg/tests/test_linalg.py -<https://github.com/numpy/numpy/blob/master/numpy/linalg/tests/test_linalg.py>`__:: +<https://github.com/numpy/numpy/blob/main/numpy/linalg/tests/test_linalg.py>`__:: class LinalgTestCase: def test_single(self): diff --git a/doc/neps/nep-0000.rst b/doc/neps/nep-0000.rst index 590976081..7f841b7e2 100644 --- a/doc/neps/nep-0000.rst +++ b/doc/neps/nep-0000.rst @@ -278,7 +278,7 @@ References and Footnotes .. [1] This historical record is available by the normal git commands for retrieving older revisions, and can also be browsed on - `GitHub <https://github.com/numpy/numpy/tree/master/doc/neps>`_. + `GitHub <https://github.com/numpy/numpy/tree/main/doc/neps>`_. .. [2] The URL for viewing NEPs on the web is https://www.numpy.org/neps/. diff --git a/doc/neps/nep-0001-npy-format.rst b/doc/neps/nep-0001-npy-format.rst index 3a28247ab..fdf4ae47a 100644 --- a/doc/neps/nep-0001-npy-format.rst +++ b/doc/neps/nep-0001-npy-format.rst @@ -292,7 +292,7 @@ included in the 1.9.0 release of numpy. Specifically, the file format.py in this directory implements the format as described here. - https://github.com/numpy/numpy/blob/master/numpy/lib/format.py + https://github.com/numpy/numpy/blob/main/numpy/lib/format.py References diff --git a/doc/neps/nep-0016-abstract-array.rst b/doc/neps/nep-0016-abstract-array.rst index 63ad600e9..9d21abe6f 100644 --- a/doc/neps/nep-0016-abstract-array.rst +++ b/doc/neps/nep-0016-abstract-array.rst @@ -141,7 +141,7 @@ Notes: In practice, either way we'd only do the full test after first checking for well-known types like ``ndarray``, ``list``, etc. `This is how NumPy currently checks for other double-underscore attributes -<https://github.com/numpy/numpy/blob/master/numpy/core/src/private/get_attr_string.h>`__ +<https://github.com/numpy/numpy/blob/main/numpy/core/src/private/get_attr_string.h>`__ and the same idea applies here to either approach. So these numbers won't affect the common case, just the case where we actually have an ``AbstractArray``, or else another third-party object that will end up diff --git a/doc/neps/nep-0023-backwards-compatibility.rst b/doc/neps/nep-0023-backwards-compatibility.rst index bdf78b05a..8b6f4cd11 100644 --- a/doc/neps/nep-0023-backwards-compatibility.rst +++ b/doc/neps/nep-0023-backwards-compatibility.rst @@ -95,10 +95,10 @@ that can be used to assess such impact include: analysis tools to determine where and how the functionality is used. - Test prominent downstream libraries against a development build of NumPy containing the proposed change to get real-world data on its impact. -- Make a change in master and revert it before release if it causes problems. - We encourage other packages to test against NumPy's master branch and if - that's too burdensome, then at least to test pre-releases. This often - turns up issues quickly. +- Make a change on the main branch and revert it before release if it + causes problems. We encourage other packages to test against + NumPy's main branch and if that's too burdensome, then at least to + test pre-releases. This often turns up issues quickly. Alternatives to deprecations ```````````````````````````` @@ -279,8 +279,8 @@ introduced for v1.11.0 and turned into a hard error for v1.12.0. This change was disruptive, however it did catch real bugs in, e.g., SciPy and scikit-learn. Overall the change was worth the cost, and introducing it in -master first to allow testing, then removing it again before a release, is a -useful strategy. +the main branch first to allow testing, then removing it again before +a release, is a useful strategy. Similar deprecations that also look like good examples of cleanups/improvements: diff --git a/doc/neps/nep-0024-missing-data-2.rst b/doc/neps/nep-0024-missing-data-2.rst index 8e63629f3..903ece1ba 100644 --- a/doc/neps/nep-0024-missing-data-2.rst +++ b/doc/neps/nep-0024-missing-data-2.rst @@ -14,7 +14,7 @@ Abstract -------- *Context: this NEP was written as an alternative to NEP 12, which at the time of writing -had an implementation that was merged into the NumPy master branch.* +had an implementation that was merged into the NumPy main branch.* The principle of this NEP is to separate the APIs for masking and for missing values, according to diff --git a/doc/neps/nep-0025-missing-data-3.rst b/doc/neps/nep-0025-missing-data-3.rst index 81045652e..1756ce491 100644 --- a/doc/neps/nep-0025-missing-data-3.rst +++ b/doc/neps/nep-0025-missing-data-3.rst @@ -14,7 +14,7 @@ Abstract *Context: this NEP was written as an additional alternative to NEP 12 (NEP 24 is another alternative), which at the time of writing had an implementation -that was merged into the NumPy master branch.* +that was merged into the NumPy main branch.* To try and make more progress on the whole missing values/masked arrays/... debate, it seems useful to have a more technical discussion of the pieces diff --git a/doc/neps/nep-0026-missing-data-summary.rst b/doc/neps/nep-0026-missing-data-summary.rst index f25ce9b91..49d89d828 100644 --- a/doc/neps/nep-0026-missing-data-summary.rst +++ b/doc/neps/nep-0026-missing-data-summary.rst @@ -17,7 +17,7 @@ The debate about how NumPy should handle missing data, a subject with many preexisting approaches, requirements, and conventions, has been long and contentious. There has been more than one proposal for how to implement support into NumPy, and there is a testable implementation which is -merged into NumPy's current master. The vast number of emails and differing +merged into NumPy's current main. The vast number of emails and differing points of view has made it difficult for interested parties to understand the issues and be comfortable with the direction NumPy is going. @@ -565,7 +565,7 @@ Recommendations for Moving Forward we're going to have to figure out how to experiment with such changes out-of-core if NumPy is to continue to evolve without forking -- might as well do it now. The existing code can live in - master, disabled, or it can live in a branch -- it'll still be there + the main branch, be disabled, or live its own branch -- it'll still be there once we know what we're doing. **Mark** thinks we should: @@ -576,8 +576,8 @@ Recommendations for Moving Forward A more detailed rationale for this recommendation is: * A solid preliminary NA-mask implementation is currently in NumPy - master. This implementation has been extensively tested - against scipy and other third-party packages, and has been in master + main. This implementation has been extensively tested + against scipy and other third-party packages, and has been in main in a stable state for a significant amount of time. * This implementation integrates deeply with the core, providing an interface which is usable in the same way R's NA support is. It diff --git a/doc/neps/nep-0036-fair-play.rst b/doc/neps/nep-0036-fair-play.rst index 4c8195b71..34c8f6eb8 100644 --- a/doc/neps/nep-0036-fair-play.rst +++ b/doc/neps/nep-0036-fair-play.rst @@ -48,7 +48,7 @@ identifying the problematic release, locating alterations, and determining an appropriate course of action. During a community call on `October 16th, 2019 -<https://github.com/numpy/archive/blob/master/status_meetings/status-2019-10-16.md>`__ +<https://github.com/numpy/archive/blob/main/status_meetings/status-2019-10-16.md>`__ the community resolved to draft guidelines on the distribution of modified NumPy versions. diff --git a/doc/neps/nep-0046-sponsorship-guidelines.rst b/doc/neps/nep-0046-sponsorship-guidelines.rst index bce125212..b8b312aa5 100644 --- a/doc/neps/nep-0046-sponsorship-guidelines.rst +++ b/doc/neps/nep-0046-sponsorship-guidelines.rst @@ -240,7 +240,7 @@ Discussion References and Footnotes ------------------------ -- `Inside NumPy: preparing for the next decade <https://github.com/numpy/archive/blob/master/content/inside_numpy_presentation_SciPy2019.pdf>`__ presentation at SciPy'19 discussing the impact of the first NumPy grant. +- `Inside NumPy: preparing for the next decade <https://github.com/numpy/archive/blob/main/content/inside_numpy_presentation_SciPy2019.pdf>`__ presentation at SciPy'19 discussing the impact of the first NumPy grant. - `Issue <https://github.com/numpy/numpy/issues/13393>`__ and `email <https://mail.python.org/pipermail/numpy-discussion/2019-April/079371.html>`__ where IBM offered a $5,000 bounty for VSX SIMD support diff --git a/doc/source/conf.py b/doc/source/conf.py index 7eb96eb22..dcf60ada9 100644 --- a/doc/source/conf.py +++ b/doc/source/conf.py @@ -94,6 +94,7 @@ templates_path = ['_templates'] # The suffix of source filenames. source_suffix = '.rst' +# Will change to `root_doc` in Sphinx 4 master_doc = 'index' # General substitutions. @@ -442,7 +443,7 @@ def linkcode_resolve(domain, info): linespec = "" if 'dev' in numpy.__version__: - return "https://github.com/numpy/numpy/blob/master/numpy/%s%s" % ( + return "https://github.com/numpy/numpy/blob/main/numpy/%s%s" % ( fn, linespec) else: return "https://github.com/numpy/numpy/blob/v%s/numpy/%s%s" % ( diff --git a/doc/source/dev/development_workflow.rst b/doc/source/dev/development_workflow.rst index 34535b2f5..8c56f6fb2 100644 --- a/doc/source/dev/development_workflow.rst +++ b/doc/source/dev/development_workflow.rst @@ -49,10 +49,10 @@ First, fetch new commits from the ``upstream`` repository: git fetch upstream -Then, create a new branch based on the master branch of the upstream +Then, create a new branch based on the main branch of the upstream repository:: - git checkout -b my-new-feature upstream/master + git checkout -b my-new-feature upstream/main .. _editing-workflow: @@ -147,7 +147,7 @@ In more detail It may be the case that while you were working on your edits, new commits have been added to ``upstream`` that affect your work. In this case, follow the -:ref:`rebasing-on-master` section of this document to apply those changes to +:ref:`rebasing-on-main` section of this document to apply those changes to your branch. .. _writing-the-commit-message: @@ -226,10 +226,10 @@ mailing list may also be useful. -.. _rebasing-on-master: +.. _rebasing-on-main: -Rebasing on master -================== +Rebasing on main +================ This updates your feature branch with changes from the upstream `NumPy github`_ repo. If you do not absolutely need to do this, try to avoid doing @@ -244,8 +244,8 @@ Next, you need to update the feature branch:: git checkout my-new-feature # make a backup in case you mess up git branch tmp my-new-feature - # rebase on upstream master branch - git rebase upstream/master + # rebase on upstream main branch + git rebase upstream/main If you have made changes to files that have changed also upstream, this may generate merge conflicts that you need to resolve. See @@ -258,7 +258,7 @@ Finally, remove the backup branch upon a successful rebase:: .. note:: - Rebasing on master is preferred over merging upstream back to your + Rebasing on main is preferred over merging upstream back to your branch. Using ``git merge`` and ``git pull`` is discouraged when working on feature branches. @@ -325,7 +325,7 @@ Suppose that the commit history looks like this:: 29001ed Add pre-nep for a couple of structured_array_extensions. ... -and ``6ad92e5`` is the last commit in the ``master`` branch. Suppose we +and ``6ad92e5`` is the last commit in the ``main`` branch. Suppose we want to make the following changes: * Rewrite the commit message for ``13d7934`` to something more sensible. @@ -392,7 +392,7 @@ Deleting a branch on github_ :: - git checkout master + git checkout main # delete branch locally git branch -D my-unwanted-branch # delete branch on github @@ -451,25 +451,25 @@ Backporting =========== Backporting is the process of copying new feature/fixes committed in -`numpy/master`_ back to stable release branches. To do this you make a branch +`numpy/main`_ back to stable release branches. To do this you make a branch off the branch you are backporting to, cherry pick the commits you want from -``numpy/master``, and then submit a pull request for the branch containing the +``numpy/main``, and then submit a pull request for the branch containing the backport. 1. First, you need to make the branch you will work on. This needs to be - based on the older version of NumPy (not master):: + based on the older version of NumPy (not main):: # Make a new branch based on numpy/maintenance/1.8.x, # backport-3324 is our new name for the branch. git checkout -b backport-3324 upstream/maintenance/1.8.x -2. Now you need to apply the changes from master to this branch using +2. Now you need to apply the changes from main to this branch using `git cherry-pick`_:: # Update remote git fetch upstream # Check the commit log for commits to cherry pick - git log upstream/master + git log upstream/main # This pull request included commits aa7a047 to c098283 (inclusive) # so you use the .. syntax (for a range of commits), the ^ makes the # range inclusive. @@ -480,7 +480,7 @@ backport. 3. You might run into some conflicts cherry picking here. These are resolved the same way as merge/rebase conflicts. Except here you can - use `git blame`_ to see the difference between master and the + use `git blame`_ to see the difference between main and the backported branch to make sure nothing gets screwed up. 4. Push the new branch to your Github repository:: @@ -488,8 +488,8 @@ backport. git push -u origin backport-3324 5. Finally make a pull request using Github. Make sure it is against the - maintenance branch and not master, Github will usually suggest you - make the pull request against master. + maintenance branch and not main, Github will usually suggest you + make the pull request against main. .. _pushing-to-main: @@ -499,7 +499,7 @@ Pushing changes to the main repo *Requires commit rights to the main NumPy repo.* When you have a set of "ready" changes in a feature branch ready for -NumPy's ``master`` or ``maintenance`` branches, you can push +NumPy's ``main`` or ``maintenance`` branches, you can push them to ``upstream`` as follows: 1. First, merge or rebase on the target branch. @@ -507,23 +507,23 @@ them to ``upstream`` as follows: a) Only a few, unrelated commits then prefer rebasing:: git fetch upstream - git rebase upstream/master + git rebase upstream/main - See :ref:`rebasing-on-master`. + See :ref:`rebasing-on-main`. b) If all of the commits are related, create a merge commit:: git fetch upstream - git merge --no-ff upstream/master + git merge --no-ff upstream/main 2. Check that what you are going to push looks sensible:: - git log -p upstream/master.. + git log -p upstream/main.. git log --oneline --graph 3. Push to upstream:: - git push upstream my-feature-branch:master + git push upstream my-feature-branch:main .. note:: diff --git a/doc/source/dev/gitwash/development_setup.rst b/doc/source/dev/gitwash/development_setup.rst index a7e9c28b9..badb73ca0 100644 --- a/doc/source/dev/gitwash/development_setup.rst +++ b/doc/source/dev/gitwash/development_setup.rst @@ -100,8 +100,8 @@ Make the local copy #. Set up your repository so ``git pull`` pulls from ``upstream`` by default: :: - git config branch.master.remote upstream - git config branch.master.merge refs/heads/master + git config branch.main.remote upstream + git config branch.main.merge refs/heads/main ****************************************************************************** Look it over @@ -109,17 +109,17 @@ Look it over #. The branches shown by ``git branch -a`` will include - - the ``master`` branch you just cloned on your own machine - - the ``master`` branch from your fork on GitHub, which git named + - the ``main`` branch you just cloned on your own machine + - the ``main`` branch from your fork on GitHub, which git named ``origin`` by default - - the ``master`` branch on the the main NumPy repo, which you named + - the ``main`` branch on the the main NumPy repo, which you named ``upstream``. :: - master - remotes/origin/master - remotes/upstream/master + main + remotes/origin/main + remotes/upstream/main If ``upstream`` isn't there, it will be added after you access the NumPy repo with a command like ``git fetch`` or ``git pull``. @@ -139,8 +139,8 @@ Look it over user.name=Your Name remote.origin.url=git@github.com:your-github-id/numpy.git remote.origin.fetch=+refs/heads/*:refs/remotes/origin/* - branch.master.remote=upstream - branch.master.merge=refs/heads/master + branch.main.remote=upstream + branch.main.merge=refs/heads/main remote.upstream.url=https://github.com/numpy/numpy.git remote.upstream.fetch=+refs/heads/*:refs/remotes/upstream/* diff --git a/doc/source/dev/gitwash/dot2_dot3.rst b/doc/source/dev/gitwash/dot2_dot3.rst index 7759e2e60..30852b5ad 100644 --- a/doc/source/dev/gitwash/dot2_dot3.rst +++ b/doc/source/dev/gitwash/dot2_dot3.rst @@ -7,22 +7,22 @@ Thanks to Yarik Halchenko for this explanation. Imagine a series of commits A, B, C, D... Imagine that there are two -branches, *topic* and *master*. You branched *topic* off *master* when -*master* was at commit 'E'. The graph of the commits looks like this:: +branches, *topic* and *main*. You branched *topic* off *main* when +*main* was at commit 'E'. The graph of the commits looks like this:: A---B---C topic / - D---E---F---G master + D---E---F---G main Then:: - git diff master..topic + git diff main..topic will output the difference from G to C (i.e. with effects of F and G), while:: - git diff master...topic + git diff main...topic would output just differences in the topic branch (i.e. only A, B, and C). diff --git a/doc/source/dev/gitwash/git_links.inc b/doc/source/dev/gitwash/git_links.inc index 8032dca41..8126cf9ac 100644 --- a/doc/source/dev/gitwash/git_links.inc +++ b/doc/source/dev/gitwash/git_links.inc @@ -47,7 +47,7 @@ .. _ipython git workflow: https://mail.python.org/pipermail/ipython-dev/2010-October/005632.html .. _git parable: http://tom.preston-werner.com/2009/05/19/the-git-parable.html .. _git foundation: http://matthew-brett.github.com/pydagogue/foundation.html -.. _numpy/master: https://github.com/numpy/numpy +.. _numpy/main: https://github.com/numpy/numpy .. _git cherry-pick: https://www.kernel.org/pub/software/scm/git/docs/git-cherry-pick.html .. _git blame: https://www.kernel.org/pub/software/scm/git/docs/git-blame.html .. _this blog post: https://github.com/blog/612-introducing-github-compare-view diff --git a/doc/source/dev/governance/governance.rst b/doc/source/dev/governance/governance.rst index 9209f26b7..8c9cc0825 100644 --- a/doc/source/dev/governance/governance.rst +++ b/doc/source/dev/governance/governance.rst @@ -381,7 +381,7 @@ A list of current Institutional Partners is maintained at the page Document history ================ -https://github.com/numpy/numpy/commits/master/doc/source/dev/governance/governance.rst +https://github.com/numpy/numpy/commits/main/doc/source/dev/governance/governance.rst Acknowledgements ================ diff --git a/doc/source/dev/index.rst b/doc/source/dev/index.rst index bcd144d71..30d9742a0 100644 --- a/doc/source/dev/index.rst +++ b/doc/source/dev/index.rst @@ -78,8 +78,8 @@ Here's the short summary, complete TOC links are below: * Pull the latest changes from upstream:: - git checkout master - git pull upstream master + git checkout main + git pull upstream main * Create a branch for the feature you want to work on. Since the branch name will appear in the merge message, use a sensible name @@ -173,13 +173,13 @@ Here's the short summary, complete TOC links are below: For a more detailed discussion, read on and follow the links at the bottom of this page. -Divergence between ``upstream/master`` and your feature branch --------------------------------------------------------------- +Divergence between ``upstream/main`` and your feature branch +------------------------------------------------------------ If GitHub indicates that the branch of your Pull Request can no longer be merged automatically, you have to incorporate changes that have been made since you started into your branch. Our recommended way to do this is to -:ref:`rebase on master<rebasing-on-master>`. +:ref:`rebase on main <rebasing-on-main>`. .. _guidelines: diff --git a/doc/source/dev/reviewer_guidelines.rst b/doc/source/dev/reviewer_guidelines.rst index 0b225b9b6..1d93bc136 100644 --- a/doc/source/dev/reviewer_guidelines.rst +++ b/doc/source/dev/reviewer_guidelines.rst @@ -74,8 +74,8 @@ For maintainers - Make sure all automated CI tests pass before merging a PR, and that the :ref:`documentation builds <building-docs>` without any errors. -- In case of merge conflicts, ask the PR submitter to :ref:`rebase on master - <rebasing-on-master>`. +- In case of merge conflicts, ask the PR submitter to :ref:`rebase on main + <rebasing-on-main>`. - For PRs that add new features or are in some way complex, wait at least a day or two before merging it. That way, others get a chance to comment before the code goes in. Consider adding it to the release notes. diff --git a/doc/source/docs/howto_build_docs.rst b/doc/source/docs/howto_build_docs.rst index 29912a5af..5db67b9b8 100644 --- a/doc/source/docs/howto_build_docs.rst +++ b/doc/source/docs/howto_build_docs.rst @@ -81,7 +81,7 @@ pdf format is also built with ``make dist``. See `HOWTO RELEASE`_ for details on how to update https://numpy.org/doc. .. _Matplotlib: https://matplotlib.org/ -.. _HOWTO RELEASE: https://github.com/numpy/numpy/blob/master/doc/HOWTO_RELEASE.rst.txt +.. _HOWTO RELEASE: https://github.com/numpy/numpy/blob/main/doc/HOWTO_RELEASE.rst.txt Sphinx extensions ----------------- diff --git a/doc/source/user/how-to-how-to.rst b/doc/source/user/how-to-how-to.rst index de8afc28a..a3be0729b 100644 --- a/doc/source/user/how-to-how-to.rst +++ b/doc/source/user/how-to-how-to.rst @@ -115,4 +115,4 @@ Is this page an example of a how-to? ******************************************************************************
Yes -- until the sections with question-mark headings; they explain rather
-than giving directions. In a how-to, those would be links.
\ No newline at end of file +than giving directions. In a how-to, those would be links.
diff --git a/numpy/_version.py b/numpy/_version.py index 6605bf4af..dcc0c5573 100644 --- a/numpy/_version.py +++ b/numpy/_version.py @@ -1,4 +1,3 @@ - # This file helps to compute a version number in source trees obtained from # git-archive tarball (such as those provided by githubs download-from-tag # feature). Distribution tarballs (built by setup.py sdist) and build @@ -191,7 +190,7 @@ def git_versions_from_keywords(keywords, tag_prefix, verbose): # refs/heads/ and refs/tags/ prefixes that would let us distinguish # between branches and tags. By ignoring refnames without digits, we # filter out many common branch names like "release" and - # "stabilization", as well as "HEAD" and "master". + # "stabilization", as well as "HEAD" and "main". tags = set([r for r in refs if re.search(r'\d', r)]) if verbose: print("discarding '%s', no digits" % ",".join(refs - tags)) diff --git a/numpy/core/src/multiarray/ctors.c b/numpy/core/src/multiarray/ctors.c index 52f21b61f..70ca96a2d 100644 --- a/numpy/core/src/multiarray/ctors.c +++ b/numpy/core/src/multiarray/ctors.c @@ -1150,7 +1150,7 @@ _array_from_buffer_3118(PyObject *memoryview) * bpo-32780 * bpo-32782 * - * Note that even if the above are fixed in master, we have to drop the + * Note that even if the above are fixed in main, we have to drop the * early patch versions of python to actually make use of the fixes. */ if (!npy_ctypes_check(Py_TYPE(view->obj))) { diff --git a/shippable.yml b/shippable.yml index 2843377e2..f26055232 100644 --- a/shippable.yml +++ b/shippable.yml @@ -1,6 +1,6 @@ branches: only: - - master + - main - maintenance/* language: python diff --git a/tools/ci/push_docs_to_repo.py b/tools/ci/push_docs_to_repo.py index ae5305484..939a09c58 100755 --- a/tools/ci/push_docs_to_repo.py +++ b/tools/ci/push_docs_to_repo.py @@ -56,7 +56,7 @@ run(['git', 'commit', '--allow-empty', '-m', args.message], stdout=False) print('- uploading as %s <%s>' % (args.committer, args.email)) if args.force: - run(['git', 'push', 'origin', 'master', '--force']) + run(['git', 'push', 'origin', 'main', '--force']) else: print('\n!! No `--force` argument specified; aborting') print('!! Before enabling that flag, make sure you know what it does\n') diff --git a/tools/travis-test.sh b/tools/travis-test.sh index 6d8d14757..ac5145411 100755 --- a/tools/travis-test.sh +++ b/tools/travis-test.sh @@ -42,7 +42,7 @@ setup_base() # Travis typically has a stable numpy release pre-installed, and if we # don't remove it, then we can accidentally end up e.g. running old # test modules that were in the stable release but have been removed - # from master. (See gh-2765, gh-2768.) Using 'pip install' also has + # from main. (See gh-2765, gh-2768.) Using 'pip install' also has # the advantage that it tests that numpy is 'pip install' compatible, # see e.g. gh-2766... if [ -z "$USE_DEBUG" ]; then |