Sending Git patches to me manually
Background
While people do understand that relying on GitHub as a centralized git forge for open source projects is a liability, there is currently no (widely accepted, web-based) decentralized alternative.
However, Git itself is inherently decentralized, if you're comfortable with the CLI.
I have several projects which are not hosted on GitHub. For some I publish the git information statically, but most are on TildeGit.
TildeGit is just one of many self-hosted GitTea instances. It's semi-private, hosted by ~ben (@ben@tilde.zone).
TildeGit was popular among Gemini protocol users, so I originally asked Ben for an account there in order to publish my Gemini server.
As GitHub's quality declined and I became more concerned with its influence on the open source software landscape, I moved more of my personal projects over.
But it would be a little crazy to expect you to have, or to create, a TildeGit account. So how can you send me a pull request?
Sharing patches over email
Well, Git is decentralized. Simply clone, make your changes, and commit like normal.
At this point, the "real" workflow is to use git send-email or git request-pull, to have Git send an email (in a standardized format) to the maintainer. This is the workflow used by Linux itself and many other projects. There are many tutorials covering it online.
However, it does have two large downsides: first, it requires authenticating Git with your email provider; second, it requires using email. Email is great, but it's never my first choice.
Sharing patch files
So that's actually not what I recommend doing. What you can do instead is use git format-patch.
The syntax for format-patch is [(-o|--output-directory) <dir>] commit_range. A common example would be
git format-patch HEAD~2 -o outbox
This formats the last two commits. Git will create files in the outbox folder which are a standardized plaintext representation of a commit. You can inspect them to ensure they're correct.
Now you can zip the outbox folder and transmit it to me as you would any other file: attached to an email in your GUI email application of choice, or sent via another messenger application.
I can then take these commits and apply them to my local repository with the git am tool, but authorship information and commit messages will stay intact.
This requires "out of band" communication: a service other than the Git host is required to transmit these files. But the vast majority of Git projects that I've worked on have had some other form of communication (Slack, Discord, Zulip, or email) set up. Once I learned about format-patch the prospect of using these messaging platforms for transmitting the patches themselves has been tantalizing.
Sending Pull Requests
You do have one other option, which should be obvious if you are familiar with Git, but I'll mention it for completeness.
After you've authored your commits, you can push them to a new repository with the Git forge of your choice, be that GitHub, GitLab, SourceHut, or a self-hosted Forgejo instance. You can then contact me with a request to pull your changes from your repository.
If you followed the link above and have yourgitset up to send email, you can usegit request-pullto send this request from the CLI.
This workflow is where GitHub's term "Pull Request" originates from.
This has the advantage of skipping the plaintext format and keeping the commit in Git. It preserves commit hashes and may work better for large files.
Conclusion
There is some definite friction around these workflows that is alleviated by Git forges like GitHub. And of course, a Git forge supports issues and discussion and such bookkeeping which is important for a project operating at scale.
There are some promising web-based git forges working on decentralization. At least Tangled, but also Codeberg and GitTea, are working on a way to collaborate ("in-band") in a decentralized way.
However, until those projects mature, Git is perfectly usable in a completely decentralized manner (for small projects like my own) using git format-patch.