Skip to content
Permalink
Browse files

Fix capitalization

  • Loading branch information...
kgryte committed Oct 5, 2019
1 parent d61142c commit 4173751d2f89154aab8abfd2d84b4c83a220ac69
@@ -81,9 +81,9 @@ If you want to contribute a new package, be sure to

- read and follow the [package development guide][stdlib-docs].

If you are unfamiliar with [git][git], the version control system used by GitHub and this project,
If you are unfamiliar with [Git][git], the version control system used by GitHub and this project,

- see the [git][git] docs.
- see the [Git][git] docs.
- try a tutorial, such as the [tutorial][github-git-tutorial] provided by GitHub.

Next, take a look around the project, noting the style and organization of documentation, tests, examples, benchmarks, and source implementations. Consistency is highly **prioritized** within stdlib. Thus, the more you are able to match and adhere to project conventions and style, the more likely your contribution will be accepted. While we have done our best to automate linting and style guidelines, such automation is not perfect and cannot adequately capture the inevitable exceptions and nuance to many rules. In short, the more you study existing practice, the better prepared you will be to contribute to stdlib.
@@ -142,7 +142,7 @@ Start making your changes and/or implementing the new feature. Any text you writ

#### Step 4: Commit

Ensure that you have configured [git][git] to know your name and email address.
Ensure that you have configured [Git][git] to know your name and email address.

```bash
$ git config --global user.name "Jane Doe"
@@ -156,14 +156,14 @@ $ git add files/which/changed
$ git commit
```

When writing commit messages, follow the git [style guide][stdlib-style-guides].
When writing commit messages, follow the Git [style guide][stdlib-style-guides].

#### Step 5: Sync

To incorporate recent changes from the `upstream` repository during development, you should [rebase][git-rebase] your local branch, reapplying your local commits on top of the current upstream `HEAD`. This procedure is in contrast to performing a standard [merge][git-merge], which may interleave development histories. The rationale is twofold:

1. interleaved histories make [squashing][git-rewriting-history] commits more difficult
2. a standard merge increases the risk of incomplete/broken commits appearing in the git history.
2. a standard merge increases the risk of incomplete/broken commits appearing in the [Git][git] history.

An ideal commit history is one in which, at no point in time, is the project in a broken state. While not always possible (mistakes happen), striving for this ideal facilitates time travel and software archeology.

@@ -176,7 +176,7 @@ $ git rebase upstream/develop

Tests should accompany **all** bug fixes and features. For guidance on how to write tests, consult existing tests within the project.

**Before** submitting a [pull request][github-pull-request] to the `upstream` repository, ensure that all tests pass, including linting. If git hooks have been enabled,
**Before** submitting a [pull request][github-pull-request] to the `upstream` repository, ensure that all tests pass, including linting. If [Git][git] hooks have been enabled,

```bash
$ make init
@@ -218,7 +218,7 @@ $ git commit
$ git push origin <branch>
```

Note that, once a [pull request][github-pull-request] has been made (i.e., your local repository commits have been pushed to a remote server), you should **not** perform any further [rewriting][git-rewriting-history] of git history. If the history needs modification, a contributor will modify the history during the merge process. The rationale for **not** rewriting public history is that doing so invalidates the commit history for anyone else who has pulled your changes, thus imposing additional burdens on collaborators to ensure that their local versions match the modified history.
Note that, once a [pull request][github-pull-request] has been made (i.e., your local repository commits have been pushed to a remote server), you should **not** perform any further [rewriting][git-rewriting-history] of [Git][git] history. If the history needs modification, a contributor will modify the history during the merge process. The rationale for **not** rewriting public history is that doing so invalidates the commit history for anyone else who has pulled your changes, thus imposing additional burdens on collaborators to ensure that their local versions match the modified history.

#### Step 9: Land

@@ -280,7 +280,7 @@ The project can **never** have enough tests. To address areas lacking sufficient

> By contributing documentation to the project, you are agreeing to release it under the project [license][stdlib-license].
Project documentation is localized within each package. Similar to code, you should modify documentation using [git][git]. Provided you have followed the [development guide][stdlib-development] and enabled git hooks,
Project documentation is localized within each package. Similar to code, you should modify documentation using [Git][git]. Provided you have followed the [development guide][stdlib-development] and enabled [Git][git] hooks,

```bash
$ make init
@@ -74,7 +74,7 @@ The following external libraries can be automatically downloaded and compiled fr

## Download

To acquire the source code, first navigate to the parent directory into which you want to place the project git repository. Because of this project's heavy reliance on [GNU make][make], the directory path should **not** include spaces or any other shell meta characters such as `$` or `:`, as these characters will cause [GNU make][make] and the installation process to fail.
To acquire the source code, first navigate to the parent directory into which you want to place the project [Git][git] repository. Because of this project's heavy reliance on [GNU make][make], the directory path should **not** include spaces or any other shell meta characters such as `$` or `:`, as these characters will cause [GNU make][make] and the installation process to fail.

<!-- run-disable -->

@@ -168,7 +168,7 @@ To initialize the development environment,
$ make init
```

Initializing the development environment configures git hooks and other bells and whistles to aid in development. Git hooks are especially important as they enable automatic linting and testing to ensure that code meets style specifications and does not break.
Initializing the development environment configures [Git][git] hooks and other bells and whistles to aid in development. Git hooks are especially important as they enable automatic linting and testing to ensure that code meets style specifications and does not break.

## Verification

@@ -235,7 +235,7 @@ workshops workshops
$ make install
```

will be enough to resolve these conflicts. Otherwise, remove the git repository, clone, and reinstall.
will be enough to resolve these conflicts. Otherwise, remove the [Git][git] repository, clone, and reinstall.

## Editors

@@ -38,7 +38,7 @@ List of **currently** unused domains:

## Changes

This is a living document which may be periodically updated. Please refer to the [git history for this document][stdlib-git-commit-log-domains] to view the changes.
This is a living document which may be periodically updated. Please refer to the [Git history for this document][stdlib-git-commit-log-domains] to view the changes.

## License

@@ -16,7 +16,7 @@
# See the License for the specific language governing permissions and
# limitations under the License.

# A git hook called by `git merge`, which runs when a `git pull` is performed on a local repository.
# A Git hook called by `git merge`, which runs when a `git pull` is performed on a local repository.
#
# This hook is called with the following arguments:
#
@@ -16,7 +16,7 @@
# See the License for the specific language governing permissions and
# limitations under the License.

# A git hook called by `git commit`. If this scripts exits with a non-zero status, the commit will be aborted.
# A Git hook called by `git commit`. If this scripts exits with a non-zero status, the commit will be aborted.
#
# This hook is called with no arguments.

@@ -21,7 +21,7 @@
# Define the version bump type (e.g., pre-patch, patch, pre-minor, minor, pre-major, major, pre-release):
NPM_VERSION ?=

# Define a git commit message when incrementing the project version:
# Define a Git commit message when incrementing the project version:
NPM_VERSION_MESSAGE ?=

# Define command-line options when incrementing the project version:
@@ -20,7 +20,7 @@

# VARIABLES #

# Define the path to the directory containing scripts for mining the git repository:
# Define the path to the directory containing scripts for mining the Git repository:
GIT_SCRIPTS_DIR ?= $(TOOLS_DIR)/git/scripts

# Define a directory path for when listing contributors:

0 comments on commit 4173751

Please sign in to comment.
You can’t perform that action at this time.