android/git-repo
1
Fork 0
mirror of https://gerrit.googlesource.com/git-repo synced 2024-12-21 07:16:21 +00:00
Code Issues Packages Projects Releases Wiki Activity

switch to "main" branch for development

Browse Source 
We're migrating from "master" to "main" as the default development
branch.  This only affects repo itself, not manifests.

Change-Id: I27489dd721c9a467a1c43736808cb3b3c1365433
Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/288082
Reviewed-by: Michael Mortensen <mmortensen@google.com>
Tested-by: Mike Frysinger <vapier@google.com>
This commit is contained in:
Mike Frysinger 2020-11-15 18:42:26 -05:00
parent 1f20776dbb
commit 6e89c965f4
7 changed files with 19 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
.github/workflows/test-ci.yml vendored
View File

@ -5,7 +5,7 @@ name: Test CI
on: on:
push: push:
branches: [master, repo-1, stable, maint] branches: [main, repo-1, stable, maint]
tags: [v*] tags: [v*]
jobs: jobs:

4
SUBMITTING_PATCHES.md
View File

@ -10,7 +10,7 @@
- Make corrections if requested. - Make corrections if requested.
- Verify your changes on gerrit so they can be submitted. - Verify your changes on gerrit so they can be submitted.
`git push https://gerrit-review.googlesource.com/git-repo HEAD:refs/for/master` `git push https://gerrit-review.googlesource.com/git-repo HEAD:refs/for/main`
# Long Version # Long Version
@ -150,7 +150,7 @@ Push your patches over HTTPS to the review server, possibly through
a remembered remote to make this easier in the future: a remembered remote to make this easier in the future:
git config remote.review.url https://gerrit-review.googlesource.com/git-repo git config remote.review.url https://gerrit-review.googlesource.com/git-repo
git config remote.review.push HEAD:refs/for/master git config remote.review.push HEAD:refs/for/main
git push review git push review

2
docs/internal-fs-layout.md
View File

@ -106,7 +106,7 @@ support, see the [manifest-format.md] file.
setting in the manifest (i.e. the path on the remote server) with a `.git` setting in the manifest (i.e. the path on the remote server) with a `.git`
suffix. This allows for multiple checkouts of the same remote git repo to suffix. This allows for multiple checkouts of the same remote git repo to
share their objects. For example, you could have different branches of share their objects. For example, you could have different branches of
`foo/bar.git` checked out to `foo/bar-master`, `foo/bar-release`, etc... `foo/bar.git` checked out to `foo/bar-main`, `foo/bar-release`, etc...
There will be multiple trees under `projects/` for each one, but only one There will be multiple trees under `projects/` for each one, but only one
under `project-objects/`. under `project-objects/`.

14
docs/manifest-format.md
View File

@ -142,8 +142,8 @@ Attribute `review`: Hostname of the Gerrit server where reviews
are uploaded to by `repo upload`. This attribute is optional; are uploaded to by `repo upload`. This attribute is optional;
if not specified then `repo upload` will not function. if not specified then `repo upload` will not function.
Attribute `revision`: Name of a Git branch (e.g. `master` or Attribute `revision`: Name of a Git branch (e.g. `main` or
`refs/heads/master`). Remotes with their own revision will override `refs/heads/main`). Remotes with their own revision will override
the default revision. the default revision.
### Element default ### Element default
@ -156,11 +156,11 @@ Attribute `remote`: Name of a previously defined remote element.
Project elements lacking a remote attribute of their own will use Project elements lacking a remote attribute of their own will use
this remote. this remote.
Attribute `revision`: Name of a Git branch (e.g. `master` or Attribute `revision`: Name of a Git branch (e.g. `main` or
`refs/heads/master`). Project elements lacking their own `refs/heads/main`). Project elements lacking their own
revision attribute will use this revision. revision attribute will use this revision.
Attribute `dest-branch`: Name of a Git branch (e.g. `master`). Attribute `dest-branch`: Name of a Git branch (e.g. `main`).
Project elements not setting their own `dest-branch` will inherit Project elements not setting their own `dest-branch` will inherit
this value. If this value is not set, projects will use `revision` this value. If this value is not set, projects will use `revision`
by default instead. by default instead.
@ -247,13 +247,13 @@ If not supplied the remote given by the default element is used.
Attribute `revision`: Name of the Git branch the manifest wants Attribute `revision`: Name of the Git branch the manifest wants
to track for this project. Names can be relative to refs/heads to track for this project. Names can be relative to refs/heads
(e.g. just "master") or absolute (e.g. "refs/heads/master"). (e.g. just "main") or absolute (e.g. "refs/heads/main").
Tags and/or explicit SHA-1s should work in theory, but have not Tags and/or explicit SHA-1s should work in theory, but have not
been extensively tested. If not supplied the revision given by been extensively tested. If not supplied the revision given by
the remote element is used if applicable, else the default the remote element is used if applicable, else the default
element is used. element is used.
Attribute `dest-branch`: Name of a Git branch (e.g. `master`). Attribute `dest-branch`: Name of a Git branch (e.g. `main`).
When using `repo upload`, changes will be submitted for code When using `repo upload`, changes will be submitted for code
review on this branch. If unspecified both here and in the review on this branch. If unspecified both here and in the
default element, `revision` is used instead. default element, `revision` is used instead.

4
docs/python-support.md
View File

@ -18,13 +18,13 @@ Bugfixes may be added on a best-effort basis or from the community, but largely
no new features will be added, nor is support guaranteed. no new features will be added, nor is support guaranteed.
Users can select this during `repo init` time via the [repo launcher]. Users can select this during `repo init` time via the [repo launcher].
Otherwise the default branches (e.g. stable & master) will be used which will Otherwise the default branches (e.g. stable & main) will be used which will
require Python 3. require Python 3.
This means the [repo launcher] needs to support both Python 2 & Python 3, but This means the [repo launcher] needs to support both Python 2 & Python 3, but
since it doesn't import any other repo code, this shouldn't be too problematic. since it doesn't import any other repo code, this shouldn't be too problematic.
The master branch will require Python 3.6 at a minimum. The main branch will require Python 3.6 at a minimum.
If the system has an older version of Python 3, then users will have to select If the system has an older version of Python 3, then users will have to select
the legacy Python 2 branch instead. the legacy Python 2 branch instead.

10
docs/release-process.md
View File

@ -97,7 +97,7 @@ If that tag cannot be verified, it gives up and forces the user to resolve.
## Branch management ## Branch management
All development happens on the `master` branch and should generally be stable. All development happens on the `main` branch and should generally be stable.
Since the repo launcher defaults to tracking the `stable` branch, it is not Since the repo launcher defaults to tracking the `stable` branch, it is not
normally updated until a new release is available. normally updated until a new release is available.
@ -112,7 +112,7 @@ For example, when `stable` moves from `v1.10.x` to `v1.11.x`, then the `maint`
branch will be updated from `v1.9.x` to `v1.10.x`. branch will be updated from `v1.9.x` to `v1.10.x`.
We don't have parallel release branches/series. We don't have parallel release branches/series.
Typically all tags are made against the `master` branch and then pushed to the Typically all tags are made against the `main` branch and then pushed to the
`stable` branch to make it available to the rest of the world. `stable` branch to make it available to the rest of the world.
Since repo doesn't typically see a lot of changes, this tends to be OK. Since repo doesn't typically see a lot of changes, this tends to be OK.
@ -120,10 +120,10 @@ Since repo doesn't typically see a lot of changes, this tends to be OK.
When you want to create a new release, you'll need to select a good version and When you want to create a new release, you'll need to select a good version and
create a signed tag using a key registered in repo itself. create a signed tag using a key registered in repo itself.
Typically we just tag the latest version of the `master` branch. Typically we just tag the latest version of the `main` branch.
The tag could be pushed now, but it won't be used by clients normally (since the The tag could be pushed now, but it won't be used by clients normally (since the
default `repo-rev` setting is `stable`). default `repo-rev` setting is `stable`).
This would allow some early testing on systems who explicitly select `master`. This would allow some early testing on systems who explicitly select `main`.
### Creating a signed tag ### Creating a signed tag
@ -144,7 +144,7 @@ $ export GNUPGHOME=~/.gnupg/repo/
$ gpg -K $ gpg -K
# Pick whatever branch or commit you want to tag. # Pick whatever branch or commit you want to tag.
$ r=master $ r=main
# Pick the new version. # Pick the new version.
$ t=1.12.10 $ t=1.12.10

2
docs/repo-hooks.md
View File

@ -27,7 +27,7 @@ repohooks project is updated and a hook is triggered.
For the full syntax, see the [repo manifest format](./manifest-format.md). For the full syntax, see the [repo manifest format](./manifest-format.md).
Here's a short example from Here's a short example from
[Android](https://android.googlesource.com/platform/manifest/+/master/default.xml). [Android](https://android.googlesource.com/platform/manifest/+/HEAD/default.xml).
The `<project>` line checks out the repohooks git repo to the local The `<project>` line checks out the repohooks git repo to the local
`tools/repohooks/` path. The `<repo-hooks>` line says to look in the project `tools/repohooks/` path. The `<repo-hooks>` line says to look in the project
with the name `platform/tools/repohooks` for hooks to run during the with the name `platform/tools/repohooks` for hooks to run during the