@@ 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.
### 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 — set it to the number of patchset versions you've sent so
## 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.