Contributing to code projects without GitHub

Among other methods of contributing to projects, some projects (such as my own) may offer or accept alternative means of reporting issues or submitting pull requests, often via email. This page discusses a few pathways to contributions that may not have been discussed elsewhere.

Overview: most repositories use the git send-email method, but a few repositories may accept git bundles. Check with the individual repository to see what methods they accept and what method they prefer.

If there is a contribution method that I didn't list that you feel should be listed here, please let me know via email:

gemini@me.blakes.dev

Git Bundles

Assuming you have a local working copy of the code (forked or not), it's as simple as creating a patch branch, making and committing your changes as normal, exporting your changes as a Git Bundle with `git bundle`, and attaching that to a message.

A Git bundle is just a single file that contains a set of changes. You can create one on a branch with:

This spits out a file called "filename.bundle" that contains all your commits!

That file can be uploaded wherever the repository accepts patch requests; typically, this is an email address, but some projects may accept patches in other places.

For my repositories, this is the second-preferred method for you to submit patches, behind submitting it to the repository's built in pull request tracker.

DO NOT DO THIS for a repository that doesn't ask for it. They may be expecting git send-email instead -- if that's the case, they'll be upset and it won't even be looked at, so you should use git send-email with that repository instead.

Git Send-Email

The classic approach. Sourcehut projects support this natively, and the Linux kernel and Git itself are developed this way.

A website associated with Sourcehut which explains this in much more helpful detail.

Prerequisites

You'll need to make sure the Git email tools are installed (they don't come with core Git installs these days). This is typically in a package called `git-email` or `git-send-email` -- every distribution calls it something different.

Next, you want to make sure it's configured. The website linked above shows this Git configuration template:

From the web site:

This configuration assumes direct TLS. If your provider only offers STARTTLS, set smtpencryption = tls and smtpserverport = 587.

Instructions

1. Clone the repository (or a fork, but it's not necessary). If you want to test this, Sourcehut has provided a repo for just that:

2. Make and commit your changes as normal (preferably in a branch, but I suppose that's not necessary).

3. "Push" the patch via email, using the `git send-email` command. The repository will typically tell you what email to send it to. For the example repository (and assuming only one change), try this:

The web site has another tip here:

If prompted for an In-Reply-To, you can ignore it for now (just press enter). Follow the rest of the prompts and you've done it! If you have any problems at this step, feel free to email us[1] for help. If it worked, you should see your email appear in the mailing list archives[2] momentarily!

1. email us

2. mailing list archives

File tickets to a mailing list

If a project has a mailing list for submitting bugs or feature requests, you can submit a ticket by sending an email to that address!

Please make sure you're following each list's rules and intended uses, including if a specific template or specific information is requested. If they are too vague or unclear, provide as much information as possible about your issue (such as version, where you got it, operating system and its version, expected vs actual behavior, and steps to reproduce) or, for a feature request or other type of ticket, ask for clarification in the mailing list or directly from a maintainer (particularly, the one who set up the mailing list, if that information is available).

The original Gemtext version of this page can be accessed with a Gemini client: gemini://blakes.dev/git-bundle-contrib.gmi

Gemini request details:

Original URL
gemini://blakes.dev/git-bundle-contrib.gmi
Status code
Success
Meta
text/gemini
Proxied by
A modified version of kineto

Be advised that no attempt was made to verify the remote SSL certificate.