~sircmpwn/sr.ht-docs

d6aa41c9cb43d24e0ba1c7172813d521989d5f0e — Drew DeVault 5 days ago 07eeaf7
git.sr.ht: reduce heading numbers
1 files changed, 9 insertions(+), 13 deletions(-)

M git.sr.ht/index.md
M git.sr.ht/index.md => git.sr.ht/index.md +9 -13
@@ 45,11 45,7 @@ The guidelines on resource usage are somewhat flexible. Here are some tips:
If in doubt, you're probably fine. We monitor resource usage and we'll send you
a friendly email if we notice that you're using too much.

# git.sr.ht manual

The following sections document various features of git.sr.ht.

## Sending patches upstream
# Sending patches upstream

git.sr.ht provides a web-based patch preparation UI, which you can use to
prepare changes to send upstream online. You can even use this to prepare


@@ 63,7 59,7 @@ style contribution popularized by GitHub, GitLab, and others.
  tutorial here</a> if you prefer to work from the command line.
</div>

### 1. Getting the source onto git.sr.ht
## 1. Getting the source onto git.sr.ht

If the project is already on git.sr.ht, look for the large blue "Clone repo to
your account" button to add a copy of it to your git.sr.ht repos. If the project


@@ 75,7 71,7 @@ rebase](https://git-rebase.io) as well, because many projects which use the
email-based workflow may expect you to be proficient with it. When you've
completed your work, push it to your git.sr.ht repository.

### 2. Preparing the patchset
## 2. Preparing the patchset

On the git.sr.ht website, visit your repository's summary page, and the large
blue button is replaced with "Prepare a patchset". Click this to start up the


@@ 106,7 102,7 @@ After you receive feedback (see below), you'll want to update ths number to
reflect how many revisions you've sent upstream. You can leave this at "1" for
the first submission.

### 3. Sending it upstream
## 3. Sending it upstream

After reviewing all of the details, click "Continue" to proceed to the final
step. You'll have to figure out who the emails should be sent to before


@@ 120,7 116,7 @@ Have one more quick look over the emails that have been prepared for you (you
can press "back" in your browser to revise any mistakes), then hit "Send
patchset" to send your work to the email addresses you've listed. You're done!

### 4. How to deal with feedback
## 4. How to deal with feedback

When the reviewers look over your work, they may have some comments for things
that you should change or clarify. Comments will arrive at your email address,


@@ 138,7 134,7 @@ to send the new version. Update the **patchset revision** field on step two when
you get there &mdash; set it to the number of patchset versions you've sent so
far.

## Attaching files to releases
# Attaching files to releases

git.sr.ht allows you to attach files, such as executables (aka binaries), PGP
signatures, and so on, to *annotated tags*. To create an annotated tag, run the


@@ 161,7 157,7 @@ branch, along with the new tag (this can be made the default behavior by running
"refs" page of your repository. To attach files to it, click the tag name (e.g.
"2.3.4") and use the upload form on this page.

## Push Options
# Push Options

git.sr.ht supports some git push options, which can be specified with `-o
option` or `-o option=value`.


@@ 185,7 181,7 @@ following command:
git config --add push.pushOption submit=".sourcehut/*.yml"
```

## Changing the default branch
# Changing the default branch

If you wish to change your default branch, visit the settings tab of your
repository. To rename your default branch, use something like the following:


@@ 193,7 189,7 @@ repository. To rename your default branch, use something like the following:
    git branch -m master main
    git push origin :master main:main

## Setting a custom README
# Setting a custom README

By default, if found, a `README` plaintext or `README.md` markdown file
will be rendered as the repository's README.