NYANDEV/forgejo
NYANDEV/forgejo
4
0
Fork 1
mirror of https://codeberg.org/forgejo/forgejo.git synced 2024-12-26 20:27:03 +01:00
Code Issues 2 Projects 1 Releases Packages Wiki Activity
forgejo/docs/content/doc/usage/agit-support.en-us.md
John Olheiser bb25f85ce8
Refactor docs (#23752) 
This was intended to be a small followup for
https://github.com/go-gitea/gitea/pull/23712, but...here we are.

1. Our docs currently use `slug` as the entire URL, which makes
refactoring tricky (see https://github.com/go-gitea/gitea/pull/23712).
Instead, this PR attempts to make future refactoring easier by using
slugs as an extension of the section. (Hugo terminology)
- What the above boils down to is this PR attempts to use directory
organization as URL management. e.g. `usage/comparison.en-us.md` ->
`en-us/usage/comparison/`, `usage/packages/overview.en-us.md` ->
`en-us/usage/packages/overview/`
- Technically we could even remove `slug`, as Hugo defaults to using
filename, however at least with this PR it means `slug` only needs to be
the name for the **current file** rather than an entire URL
2. This PR adds appropriate aliases (redirects) for pages, so anything
on the internet that links to our docs should hopefully not break.
3. A minor nit I've had for a while, renaming `seek-help` to `support`.
It's a minor thing, but `seek-help` has a strange connotation to it.
4. The commits are split such that you can review the first which is the
"actual" change, and the second is added redirects so that the first
doesn't break links elsewhere.

---------

Signed-off-by: jolheiser <john.olheiser@gmail.com>
2023-04-28 11:33:41 +08:00

1.5 KiB
Raw Blame History

date title slug weight toc draft aliases menu
2022-09-01T20:50:42+0000 Agit Setup agit-setup 12 false false
/en-us/agit-setup
sidebar
parent name weight identifier
usage Agit Setup 12 agit-setup

Agit Setup

In Gitea 1.13, support for agit was added.

Creating PRs with Agit

Agit allows to create PRs while pushing code to the remote repo.
This can be done by pushing to the branch followed by a specific refspec (a location identifier known to git).
The following example illustrates this:

git push origin HEAD:refs/for/master

The command has the following structure:

  • HEAD: The target branch
  • refs/<for|draft|for-review>/<branch>: The target PR type
    • for: Create a normal PR with <branch> as the target branch
    • draft/ for-review: Currently ignored silently
  • <branch>/<session>: The target branch to open the PR
  • -o <topic|title|description>: Options for the PR
    • title: The PR title
    • topic: The branch name the PR should be opened for
    • description: The PR description
    • force-push: confirm force update the target branch

Here's another advanced example for creating a new PR targeting master with topic, title, and description:

git push origin HEAD:refs/for/master -o topic="Topic of my PR" -o title="Title of the PR" -o description="# The PR Description\nThis can be **any** markdown content.\n- [x] Ok"