lunny/git-lfs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: prepare for rename of default branch name

Browse Source 
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.
This commit is contained in:
brian m. carlson 2021-02-01 21:44:22 +00:00
parent 31436a59e4
commit c0c2a25ce6
No known key found for this signature in database
GPG Key ID: 2D0C9BC12F82B3A1
4 changed files with 14 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
CONTRIBUTING.md
View File

@ -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 <my-branch-name> master`
1. Create a new branch based on `main`: `git checkout -b <my-branch-name> 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:

2
README.md
View File

@ -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:

18
docs/howto/release-git-lfs.md
View File

@ -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:

2
docs/man/git-lfs-config.5.ronn
View File

@ -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
<name> must be a unique identifier that the LFS server understands. When
calling the LFS API the client will include a list of supported transfer