From c0c2a25ce6d16c0343f7c4841bc35fc035d5359d Mon Sep 17 00:00:00 2001 From: "brian m. carlson" Date: Mon, 1 Feb 2021 21:44:22 +0000 Subject: [PATCH] docs: prepare for rename of default branch name We're going to want to rename the default branch to main, so let's update our documentation so it reflects the right branch for users to work with, for core team members to use for releases, and for the latest version of the documentation. --- CONTRIBUTING.md | 6 +++--- README.md | 2 +- docs/howto/release-git-lfs.md | 18 +++++++++--------- docs/man/git-lfs-config.5.ronn | 2 +- 4 files changed, 14 insertions(+), 14 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 2ba38839..b6ad0c38 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -50,16 +50,16 @@ The Git LFS teams mark issues and pull requests with the following labels: ## Branching strategy -In general, contributors should develop on branches based off of `master` and pull requests should be to `master`. +In general, contributors should develop on branches based off of `main` and pull requests should be to `main`. ## Submitting a pull request 1. [Fork][] and clone the repository 1. Configure and install the dependencies: `make` 1. Make sure the tests pass on your machine: `make test` -1. Create a new branch based on `master`: `git checkout -b master` +1. Create a new branch based on `main`: `git checkout -b main` 1. Make your change, add tests, and make sure the tests still pass -1. Push to your fork and [submit a pull request][pr] from your branch to `master` +1. Push to your fork and [submit a pull request][pr] from your branch to `main` 1. Pat yourself on the back and wait for your pull request to be reviewed Here are a few things you can do that will increase the likelihood of your pull request being accepted: diff --git a/README.md b/README.md index 33c02b06..64eae3a1 100644 --- a/README.md +++ b/README.md @@ -116,7 +116,7 @@ $ git commit -m "add psd" > $ git lfs migrate import --include="*.psd" --everything > ``` > -> For more information, read [`git-lfs-migrate(1)`](https://github.com/git-lfs/git-lfs/blob/master/docs/man/git-lfs-migrate.1.ronn). +> For more information, read [`git-lfs-migrate(1)`](https://github.com/git-lfs/git-lfs/blob/main/docs/man/git-lfs-migrate.1.ronn). You can confirm that Git LFS is managing your PSD file: diff --git a/docs/howto/release-git-lfs.md b/docs/howto/release-git-lfs.md index 58260838..d86f100e 100644 --- a/docs/howto/release-git-lfs.md +++ b/docs/howto/release-git-lfs.md @@ -50,13 +50,13 @@ We package several artifacts for each tagged release. They are: ## Development Philosophy -We do all major development on the `master` branch, and assume it to be passing +We do all major development on the `main` branch, and assume it to be passing tests at all times. New features are added via the feature-branch workflow, or (optionally) from a contributor's fork. -This is done so that `master` can progress and grow new features, while +This is done so that `main` can progress and grow new features, while historical releases, such as `v2.n.0` can receive bug fixes as they are applied -to master, eventually culminating in a `v2.n.1` (and so on) release. +to main, eventually culminating in a `v2.n.1` (and so on) release. ## Building a release @@ -89,7 +89,7 @@ equal to 0, we say that we are releasing a MINOR version of Git LFS, in the the relevant files. 2. Then, create a pull request of your changes with head `release-next`. If - you're building a MAJOR or MINOR release, set the base to `master`. + you're building a MAJOR or MINOR release, set the base to `main`. Otherwise, set the base to `release-2.n`. Run Continuous Integration, and ensure that it passes. @@ -171,14 +171,14 @@ equal to 0, we say that we are releasing a MINOR version of Git LFS, in the When building a MINOR release, we introduce a new `release-2.n` branch which will receive all new features and bug fixes since `release-2.n-1`. The change set described by `v2.n-1.0` and `v2.n.0` is as reported by `git log -v2.n-1.0...master` at the time of release. +v2.n-1.0...main` at the time of release. 1. To introduce this new branch (after creating and merging `release-next` - into `master`), simply run: + into `main`), simply run: ```ShellSession $ git branch - * master + * main $ git checkout -b release-2.n ``` @@ -187,7 +187,7 @@ v2.n-1.0...master` at the time of release. ### Building `v2.n.m` (PATCH versions) When building a PATCH release, follow the same process as above, with the -additional caveat that we must cherry-pick merges from master to the release +additional caveat that we must cherry-pick merges from main to the release branch. 1. To begin, checkout the branch `release-2.n`, and ensure that you have the @@ -197,7 +197,7 @@ branch. with: ```ShellSession - $ git log --merges --first-parent v2.n.m-1...master + $ git log --merges --first-parent v2.n.m-1...main ``` 3. For each merge that you want to backport, run: diff --git a/docs/man/git-lfs-config.5.ronn b/docs/man/git-lfs-config.5.ronn index 584d6571..499dc87b 100644 --- a/docs/man/git-lfs-config.5.ronn +++ b/docs/man/git-lfs-config.5.ronn @@ -133,7 +133,7 @@ be scoped inside the configuration for a remote. using any mechanism you like (rather than just HTTP). `path` should point to the process you wish to invoke. The protocol between the git-lfs client and the custom transfer process is documented at - https://github.com/git-lfs/git-lfs/blob/master/docs/custom-transfers.md + https://github.com/git-lfs/git-lfs/blob/main/docs/custom-transfers.md must be a unique identifier that the LFS server understands. When calling the LFS API the client will include a list of supported transfer