Merge branch 'worktree-agent-a713e95d8d9dc91af'
10 files+128−330/10 viewed
| 464 | 464 | ### Payments in test mode | |
| 465 | 465 | ||
| 466 | 466 | A g1t whose payments use Stripe's test mode, such as a self-hosted one set | |
| 467 | − | up with test keys, or g1t.sh before its live payments are switched on, | |
| 468 | − | charges no real card, so a card check there proves nothing. With live | |
| 469 | − | payments, the card check and every charge are real. **Status.** By design | |
| 467 | + | up with test keys, charges no real card, so a card check there proves | |
| 468 | + | nothing. g1t.sh takes live payments: the card check and every charge are | |
| 469 | + | real. **Status.** By design | |
| 470 | 470 | for test setups. | |
| 471 | 471 | ||
| 472 | 472 | ## Accounts, status and self-hosting |
| 178 | 178 | ||
| 179 | 179 | They are not free of trade-offs. | |
| 180 | 180 | ||
| 181 | − | - **Falling behind is silent.** A branch sees new commits on `main` at the | |
| 181 | + | - **Falling behind is quieter.** A branch sees new commits on `main` at the | |
| 182 | 182 | next fetch. A working copy has to pull from the original repository, | |
| 183 | − | which is a second remote. g1t tells a pull request it is behind when | |
| 184 | − | someone tries to merge it, and the fix is one pull, but its author has to | |
| 185 | − | do it. | |
| 183 | + | which is a second remote. The merge box says when a pull request is | |
| 184 | + | behind, merging brings it up to date by itself unless the branch must be | |
| 185 | + | up to date first, and its author can | |
| 186 | + | [update the branch](/guides/pull-requests/#keeping-it-up-to-date) from | |
| 187 | + | the merge box; but a clone of the working copy only has the new commits | |
| 188 | + | once its author pulls them. | |
| 186 | 189 | - **Merging does more work.** Merging from a working copy copies the new | |
| 187 | 190 | objects into the repository before moving `main`. From a branch they are | |
| 188 | 191 | already there. |
| 572 | 572 | as `ubuntu-24.04-arm`, runs on x64, and the workflow's page says so; a | |
| 573 | 573 | self-hosted Arm runner runs it on Arm. | |
| 574 | 574 | ||
| 575 | + | A workspace always has room for 4 jobs at once on g1t's machines, and runs | |
| 576 | + | up to 12 at once while the machines have room to spare; the rest stay queued, | |
| 577 | + | oldest first, and start as others finish. Some machines are always kept free, | |
| 578 | + | so another workspace's first jobs start at once. Jobs on | |
| 579 | + | [self-hosted runners](/guides/self-hosted-runners/) do not count toward | |
| 580 | + | this. | |
| 581 | + | ||
| 575 | 582 | ### What a job can reach | |
| 576 | 583 | ||
| 577 | 584 | A job reaches the internet, as on GitHub's machines: package registries, |
| 226 | 226 | A pull request whose target has a CODEOWNERS file shows **Code owners**: | |
| 227 | 227 | which rule owns which changed files, each with its section, its owners, | |
| 228 | 228 | how many approvals it needs, who has approved, and who has asked for | |
| 229 | − | changes. A rule that is satisfied, or optional, is marked so. | |
| 229 | + | changes. A rule that is satisfied, or optional, is marked so. The box's | |
| 230 | + | badge says **Approval required** or **Approval not required**. Where it is | |
| 231 | + | not required, a rule nobody has approved yet says **No approval yet** | |
| 232 | + | rather than how many approvals it waits for, since merging does not wait | |
| 233 | + | on it; a code owner who asked for changes is still shown. | |
| 230 | 234 | ||
| 231 | 235 | When the repository requires code owners' approval, the merge box lists | |
| 232 | 236 | what is missing: |
| 40 | 40 | branch, or turn it off to copy every branch and tag. | |
| 41 | 41 | 5. Choose **Create fork**. | |
| 42 | 42 | ||
| 43 | − | You land on the fork. Its header says **Forked from** and links to the | |
| 44 | − | parent. | |
| 43 | + | You land on the fork. Under its name, its header says **forked from** and | |
| 44 | + | links to the parent. | |
| 45 | 45 | ||
| 46 | 46 | From the CLI, `g1t repo fork` forks the current repository, or the one you | |
| 47 | 47 | name, into your personal workspace unless you say `--workspace`. With |
| 315 | 315 | `git push origin --all && git push origin --tags`. A push with `--atomic` | |
| 316 | 316 | that names one is refused whole. | |
| 317 | 317 | ||
| 318 | + | ## Pushes that merge pull requests and close issues | |
| 319 | + | ||
| 320 | + | A push does the same bookkeeping as merging on the site: | |
| 321 | + | ||
| 322 | + | - **It merges the pull requests it lands.** When a push to a branch brings | |
| 323 | + | in the head commit of an open pull request into that branch, by merging | |
| 324 | + | it in a clone or pushing its commits straight there, the pull request is | |
| 325 | + | marked merged by whoever pushed. The issues it closes close, as with any | |
| 326 | + | merge, and it leaves the merge queue. See [merging by pushing](/guides/pull-requests/#merging-by-pushing). | |
| 327 | + | - **It closes the issues its commits name.** A commit pushed to the | |
| 328 | + | default branch whose message says `Fixes #12`, `Closes #12` or another | |
| 329 | + | closing keyword closes that issue as completed, and the issue says which | |
| 330 | + | commit closed it and who pushed it. Up to 250 commits of a push are | |
| 331 | + | read. See [closing issues](/guides/pull-requests/#closing-issues). | |
| 332 | + | ||
| 333 | + | ```sh | |
| 334 | + | git commit -m "Greet the caller by name | |
| 335 | + | ||
| 336 | + | Closes #12" | |
| 337 | + | git push origin main | |
| 338 | + | ``` | |
| 339 | + | ||
| 340 | + | A repository whose **Auto-close issues with merged linked pull requests** | |
| 341 | + | setting is off closes no issues either way. In a commit message on g1t, | |
| 342 | + | `#12` links to that issue or pull request. | |
| 343 | + | ||
| 318 | 344 | ## Limits | |
| 319 | 345 | ||
| 320 | 346 | ### Size limits |
| 114 | 114 | | **Details** | Its website and topics, shown on its page, in [search and Explore](/guides/search/). Its description is its project's, on **General**. | | |
| 115 | 115 | | **Branches** | The default branch, renaming a branch, and a link to **Branches and merging**: [branch protection](/guides/git/#protected-branches), [required status checks](/guides/pull-requests/#required-status-checks), required approvals, and the [merge queue](/guides/merge-queue/). What a sandbox may reach is under **Guardrails**; see [guardrails](/guides/guardrails/). | | |
| 116 | 116 | | **Artifacts** | How many days the files workflow runs upload are kept, 1 to 90 (14 unless changed). See [artifacts](/guides/actions/#artifacts). | | |
| 117 | − | | **Features** | Whether it has issues. A [fork](/concepts/forks/) starts with them off. | | |
| 117 | + | | **Features** | Whether it has issues (a [fork](/concepts/forks/) starts with them off), and whether merges and commits close issues. See [issues](#issues). | | |
| 118 | + | | **Commits** | Sign-off on commits made on g1t, and comments on commits. See [commits](#commits). | | |
| 119 | + | | **Pushes** | How many branches and tags one push may update. See [pushes](#pushes). | | |
| 120 | + | | **Archives** | Whether downloads hold Git LFS objects. Coming soon. | | |
| 118 | 121 | | **Forking** | For a private repository, whether people who can read it may [fork it](/guides/forking-repositories/#allow-forking-a-private-repository). Public repositories can always be forked. | | |
| 119 | 122 | | **Danger zone** | Change visibility, archive, [transfer](/guides/transferring-repositories/), [detach a fork](/guides/forking-repositories/#detach-a-fork) and delete. Shown to people with the Admin role. | | |
| 120 | 123 | ||
| ⋯ | |||
| 131 | 134 | [`PATCH /repos/{owner}/{name}`](/reference/api/repositories/update-repo/)'s. | |
| 132 | 135 | Fields you leave out stay as they are. Changing them needs the Maintain | |
| 133 | 136 | [role](/guides/access-and-roles/) or higher; `max_ref_updates` needs Admin. | |
| 137 | + | The pull request settings are on the repository's **Settings → Branches | |
| 138 | + | and merging** page; the rest are on **Settings → Repository**, in the | |
| 139 | + | sections named below. | |
| 134 | 140 | ||
| 135 | 141 | ### Pull requests | |
| 136 | 142 | ||
| 143 | + | On **Settings → Branches and merging**, under **Merge methods**, | |
| 144 | + | **Updating branches**, **Auto-merge** and **After merging**. Merge commits | |
| 145 | + | and squash merging, the two methods that write a commit message, each have | |
| 146 | + | a **Default commit message** and, with **Custom template**, a **Template**, | |
| 147 | + | with a preview of the message it makes. | |
| 148 | + | ||
| 137 | 149 | | Setting | Field | Default | What it does | | |
| 138 | 150 | | --- | --- | --- | --- | | |
| 139 | 151 | | Allow merge commits | `allow_merge_commit` | On | Pull requests may merge with a merge commit (`merge`). | | |
| ⋯ | |||
| 141 | 153 | | Allow rebase merging | `allow_rebase_merge` | On | They may merge by making each commit again on the base (`rebase`). | | |
| 142 | 154 | | Allow fast-forward merging | `allow_fast_forward` | Off | They may merge by moving the base to their head, with no new commit (`fast_forward`). | | |
| 143 | 155 | | Default merge method | `default_merge_method` | `merge` | The method the merge button offers first, and the one a merge that names none uses. It must be allowed. | | |
| 144 | − | | Default merge commit message | `merge_commit_message` | `default` | What a merge commit says unless its merger writes it: `default`, `pull_title`, `pull_title_and_description` or `custom`. | | |
| 145 | − | | Default squash commit message | `squash_commit_message` | `default` | What a squash commit says: the same, and `pull_title_and_commits`. | | |
| 146 | − | | Merge and squash commit templates | `merge_commit_template`, `squash_commit_template` | None | The message used with `custom`, with [placeholders](/guides/pull-requests/#commit-messages). An empty string clears it. | | |
| 147 | − | | Always suggest updating branches | `suggest_updating_branches` | On | Offer to update a pull request's branch whenever its base has new commits, not only when it must be up to date. | | |
| 156 | + | | Default commit message, under Allow merge commits | `merge_commit_message` | `default` | What a merge commit says unless its merger writes it: **Default message** (`default`), **Pull request title** (`pull_title`), **Pull request title and description** (`pull_title_and_description`) or **Custom template** (`custom`). | | |
| 157 | + | | Default commit message, under Allow squash merging | `squash_commit_message` | `default` | What a squash commit says: the same, and **Pull request title and commit details** (`pull_title_and_commits`). | | |
| 158 | + | | Template | `merge_commit_template`, `squash_commit_template` | None | The message used with `custom`, with [placeholders](/guides/pull-requests/#commit-messages). An empty string clears it. | | |
| 159 | + | | Always suggest updating pull request branches | `suggest_updating_branches` | On | Offer to update a pull request's branch whenever its base has new commits, not only when it must be up to date. | | |
| 148 | 160 | | Allow auto-merge | `allow_auto_merge` | On | People may turn on [auto-merge](/guides/pull-requests/#auto-merge) for a pull request. | | |
| 149 | − | | Delete branches when they merge | `delete_branch_on_merge` | Off | A pull request's branch is deleted once it merges. It can be [restored](/guides/pull-requests/#deleting-the-branch) from the pull request. | | |
| 161 | + | | Automatically delete head branches | `delete_branch_on_merge` | Off | A pull request's branch is deleted once it merges. It can be [restored](/guides/pull-requests/#deleting-the-branch) from the pull request. | | |
| 150 | 162 | ||
| 151 | 163 | At least one method stays allowed. [Rules](/guides/rules/#pull-requests-and-checks) | |
| 152 | 164 | can narrow the methods for a branch, with `allowed_merge_methods` and | |
| ⋯ | |||
| 154 | 166 | ||
| 155 | 167 | ### Commits | |
| 156 | 168 | ||
| 169 | + | On **Settings → Repository**, under **Commits**. | |
| 170 | + | ||
| 157 | 171 | | Setting | Field | Default | What it does | | |
| 158 | 172 | | --- | --- | --- | --- | | |
| 159 | − | | Require sign-off on web commits | `require_web_commit_sign_off` | Off | Commits made on g1t (web edits, merge and squash commits) end with a `Signed-off-by:` trailer for whoever made them, agreeing to the repository's terms, commonly the Developer Certificate of Origin. | | |
| 160 | − | | Allow comments on commits | `allow_commit_comments` | On | Anyone who can read the repository may [comment on its commits](/guides/pull-requests/#commit-comments). Off keeps existing comments readable and refuses new ones. | | |
| 173 | + | | Require contributors to sign off on web-based commits | `require_web_commit_sign_off` | Off | Commits made on g1t (web edits, merge and squash commits) end with a `Signed-off-by:` trailer for whoever made them, agreeing to the repository's terms, commonly the Developer Certificate of Origin. | | |
| 174 | + | | Allow comments on individual commits | `allow_commit_comments` | On | Anyone who can read the repository may [comment on its commits](/guides/pull-requests/#commit-comments). Off keeps existing comments readable and refuses new ones. | | |
| 161 | 175 | ||
| 162 | 176 | ### Pushes | |
| 163 | 177 | ||
| 178 | + | On **Settings → Repository**, under **Pushes**. Turned on, it asks for | |
| 179 | + | **Most branches and tags per push**. | |
| 180 | + | ||
| 164 | 181 | | Setting | Field | Default | What it does | | |
| 165 | 182 | | --- | --- | --- | --- | | |
| 166 | − | | Limit how many branches and tags a push can update | `max_ref_updates` | No limit | The most branches and tags one push may create, move or delete, 1 to 1,000. A push that would change more is declined whole, so nothing of it lands: "This push changes N branches and tags; owner/name takes at most M at a time. Push fewer at once." `0` removes the limit. | | |
| 183 | + | | Limit how many branches and tags can be updated in a single push | `max_ref_updates` | No limit | The most branches and tags one push may create, move or delete, 1 to 1,000. A push that would change more is declined whole, so nothing of it lands: "This push changes N branches and tags; owner/name takes at most M at a time. Push fewer at once." `0` removes the limit. | | |
| 167 | 184 | ||
| 168 | 185 | ### Archives | |
| 169 | 186 | ||
| 187 | + | On **Settings → Repository**, under **Archives**. | |
| 188 | + | ||
| 170 | 189 | | Setting | Field | Default | What it does | | |
| 171 | 190 | | --- | --- | --- | --- | | |
| 172 | 191 | | Include Git LFS objects in archives | None yet | Off | Coming soon. g1t does not store Git LFS files yet (see [limitations](/about/limitations/)), so archives hold what git stores; the setting is shown, turned off, until it does. | | |
| 173 | 192 | ||
| 174 | 193 | ### Issues | |
| 175 | 194 | ||
| 195 | + | On **Settings → Repository**, under **Features**. | |
| 196 | + | ||
| 176 | 197 | | Setting | Field | Default | What it does | | |
| 177 | 198 | | --- | --- | --- | --- | | |
| 178 | 199 | | Issues | `has_issues` | On; off for a [fork](/concepts/forks/) | Whether issues can be opened. Off keeps existing issues readable. `null` goes back to the default. `issues_enabled` says whether they can be opened now. | | |
| 179 | − | | Close issues when pull requests merge | `auto_close_issues` | On | A pull request that merges into the default branch closes its issue and those it names after a [closing keyword](/guides/pull-requests/#closing-issues), and so does a commit pushed to the default branch whose message names them. | | |
| 200 | + | | Auto-close issues with merged linked pull requests | `auto_close_issues` | On | A pull request that merges into the default branch closes its issue and those it names after a [closing keyword](/guides/pull-requests/#closing-issues), and so does a commit pushed to the default branch whose message names them. | | |
| 180 | 201 | ||
| 181 | 202 | ```sh | |
| 182 | 203 | curl -X PATCH https://api.g1t.sh/repos/acme/rocket/settings \ | |
| 64 | 64 | again on the same commit. Every push to the pull request runs its workflows | |
| 65 | 65 | again on the new head. | |
| 66 | 66 | ||
| 67 | + | g1t's own **Dependency review** check has **Re-run dependency review** | |
| 68 | + | beside it, for the same people, since advisories are published every day: | |
| 69 | + | it reviews the head again and updates the check and its one comment. See | |
| 70 | + | [dependency review](/guides/security/supply-chain/#dependency-review). | |
| 71 | + | ||
| 67 | 72 | ### A repository with no checks | |
| 68 | 73 | ||
| 69 | 74 | When a repository has no workflows, the merge box says **This repository | |
| ⋯ | |||
| 171 | 176 | When the repository has a [CODEOWNERS file](/guides/codeowners/), the | |
| 172 | 177 | owners of the files a pull request changes are asked by themselves, and | |
| 173 | 178 | the pull request shows **Code owners**: who owns which files and whose | |
| 174 | − | approval is still needed. | |
| 179 | + | approval is still needed. Where the rules do not require code owners' | |
| 180 | + | approval, the box says **Approval not required**, and a rule nobody has | |
| 181 | + | approved yet says **No approval yet**: nothing is waiting on it. | |
| 175 | 182 | ||
| 176 | 183 | Through the API, `POST /repos/{owner}/{name}/pulls/{number}/requested_reviewers` | |
| 177 | 184 | takes `reviewers` (usernames) and `team_reviewers` (teams, as | |
| ⋯ | |||
| 180 | 187 | the MCP server they are the `pull_request` tool's `request_reviewers` and | |
| 181 | 188 | `remove_requested_reviewers` actions. | |
| 182 | 189 | ||
| 190 | + | ### Reviewing | |
| 191 | + | ||
| 192 | + | Anyone signed in other than its author can review an open pull request. | |
| 193 | + | Write in the comment box under the conversation, then choose **Comment**, | |
| 194 | + | **Approve** or **Request changes**. | |
| 195 | + | ||
| 196 | + | A review that only approves or requests changes, with nothing written and | |
| 197 | + | no line it is about, shows as one line in the conversation, the way an | |
| 198 | + | event does: who reviewed, **approved these changes** or **requested | |
| 199 | + | changes**, and when. A coding agent's review shows its name with its | |
| 200 | + | **Agent** badge and an **Advisory** chip: an agent's review never counts | |
| 201 | + | toward required approvals or code owners. A review with text, or one on a | |
| 202 | + | line of a file, keeps a card of its own, like a comment. | |
| 203 | + | ||
| 183 | 204 | ## Sessions | |
| 184 | 205 | ||
| 185 | 206 | Each session that works on a pull request, or on its issue, shows in the | |
| ⋯ | |||
| 286 | 307 | removed for everyone and cannot be brought back. | |
| 287 | 308 | ||
| 288 | 309 | A review that approved or requested changes can be edited but not deleted, | |
| 289 | − | so its verdict stays on record. The notes in the timeline of what happened, | |
| 310 | + | so its verdict stays on record. One with nothing written has nothing to | |
| 311 | + | edit, so it has neither. The notes in the timeline of what happened, | |
| 290 | 312 | such as "closed this", cannot be edited or deleted. | |
| 291 | 313 | ||
| 292 | 314 | Through the API, `PATCH /repos/{owner}/{name}/issues/comments/{comment_id}` | |
| 77 | 77 | ||
| 78 | 78 | The review's summary is commented on the pull request, a table per | |
| 79 | 79 | lockfile of what was added and removed, and the check links to | |
| 80 | − | `g1t.sh/<owner>/<project>/security/pulls/<number>`. Require **Dependency | |
| 81 | − | review** under **Settings → Branches** to block merges on it. | |
| 80 | + | `g1t.sh/<owner>/<project>/security/pulls/<number>`. To block merges on it, | |
| 81 | + | add **Dependency review** to a ruleset's **Require status checks to pass** | |
| 82 | + | rule under **Settings → Rules** (see | |
| 83 | + | [required status checks](/guides/pull-requests/#required-status-checks)). | |
| 82 | 84 | ||
| 83 | 85 | A pull request has one review comment. When a later review says something | |
| 84 | 86 | new, that comment is changed in place; when it says the same, the comment |
| 183 | 183 | once. Otherwise, pay on the card page you are sent to. | |
| 184 | 184 | ||
| 185 | 185 | Back on Billing, the plan's card says **On the g1t plan** (**first month** | |
| 186 | − | in the first billing cycle), with the billing period, a meter for the | |
| 187 | − | month's included usage, and the **Upcoming invoice**: the plan and add-ons | |
| 186 | + | in the first billing cycle), with the usage month and the day the plan | |
| 187 | + | renews: **Usage month Oct 1 – Oct 31, 2026; the plan renews Nov 15, 2026**. | |
| 188 | + | Usage is counted by calendar month (UTC), but the plan renews on the day | |
| 189 | + | of the month it started, so a plan started mid-month renews mid-month. | |
| 190 | + | Then come a meter for the month's included usage, and the **Upcoming invoice**: the plan and add-ons | |
| 188 | 191 | at their monthly price plus usage still owed after included usage, credit | |
| 189 | 192 | and any discount, from g1t's own ledger (**View upcoming invoice** splits | |
| 190 | 193 | it). **Usage** goes to usage by product and project. App traffic, custom | |
| ⋯ | |||
| 435 | 438 | Charging starts on 2026-10-14: operations before then are never charged. | |
| 436 | 439 | **Billing** shows this month's count under **Git operations & storage**. | |
| 437 | 440 | ||
| 441 | + | A month's operations are charged in full, up to its last minute: its | |
| 442 | + | final count is taken once the month has ended (from an hour after | |
| 443 | + | midnight UTC on the 1st), and the month is charged and closed only after | |
| 444 | + | that, at the plan the workspace had that month. | |
| 445 | + | ||
| 438 | 446 | ## Storage, search embeddings and scans | |
| 439 | 447 | ||
| 440 | 448 | These are counted through the month and charged once it is over, as one | |
| ⋯ | |||
| 687 | 695 | [deleting a workspace](/guides/workspaces/#what-billing-needs). | |
| 688 | 696 | ||
| 689 | 697 | Each is charged to the card on file, with [tax](#tax) as a line of its | |
| 690 | − | own and no card fee. Every invoice and receipt, with its PDF, is on | |
| 698 | + | own and no card fee. On Stripe's payment page and on receipts, the plan is | |
| 699 | + | named **g1t plan for *workspace***, such as **g1t plan for acme**. Every invoice and receipt, with its PDF, is on | |
| 691 | 700 | Stripe's billing page: choose **Manage billing** under **Billing on | |
| 692 | 701 | Stripe**. | |
| 693 | 702 | ||
| ⋯ | |||
| 861 | 870 | - **A monthly fee of its own**, often none. When there is one, Stripe | |
| 862 | 871 | invoices it each month, apart from the allowance. | |
| 863 | 872 | ||
| 864 | − | **Billing** shows the allowance, what is used, what is metered but not | |
| 865 | − | billed yet, what is left, and when it starts again. Usage that is measured | |
| 873 | + | **Billing** has a **Complimentary allowance** card: the allowance a month | |
| 874 | + | (or **Unlimited**), the monthly fee or **No monthly fee**, and **Used**, | |
| 875 | + | **Metered, not billed yet**, **Remaining** and **Starts again**. Usage that is measured | |
| 866 | 876 | at the end of the month, such as storage and git operations, and work | |
| 867 | 877 | running now count against what is left. | |
| 868 | 878 | ||
| ⋯ | |||
| 878 | 888 | set amount of an employee's or a friend's usage. Past the allowance, | |
| 879 | 889 | usage is charged at the same prices as on the plan, up to your | |
| 880 | 890 | [spend limit](#limits) and the [ceiling](#the-ceiling), and invoiced | |
| 881 | − | when the month closes. Add a card on **Billing** first: without one, | |
| 882 | − | work stops at the allowance until you do. | |
| 891 | + | when the month closes. Add a card first, with **Add a card** on the | |
| 892 | + | allowance card: without one, work stops at the allowance until you do. | |
| 883 | 893 | ||
| 884 | 894 | If g1t changes the amount, what the month already used still counts: | |
| 885 | 895 | raising it adds only the difference, and lowering it below what was used | |
| 886 | 896 | leaves nothing more this month, never a bill. | |
| 887 | 897 | ||
| 888 | − | An owner or billing manager can **start the g1t plan instead** from the | |
| 889 | − | allowance card on **Billing**. The plan uses the same Stripe customer and | |
| 898 | + | An owner or billing manager can choose **Start the g1t plan instead** on | |
| 899 | + | the allowance card. The plan uses the same Stripe customer and | |
| 890 | 900 | subscription, and nothing changes until its first payment goes through: | |
| 891 | 901 | if the card is declined, the bank asks to confirm the payment, or the page | |
| 892 | 902 | is closed, the complimentary terms stay as they were. Usage the allowance | |
Comments
Sign in to comment.