💾 Archived View for blakes.dev › git-bundle-contrib.gmi captured on 2024-08-31 at 11:59:30. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
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:
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:
git bundle create filename.bundle main..HEAD
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.
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.
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:
[sendemail] smtpserver = mail.example.org smtpuser = you@example.org smtpencryption = ssl smtpserverport = 465
From the web site:
This configuration assumes direct TLS. If your provider only offers STARTTLS, set smtpencryption = tls and smtpserverport = 587.
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:
git clone https://git.sr.ht/~sircmpwn/email-test-drive cd email-test-drive
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:
git send-email --to="~sircmpwn/email-test-drive@lists.sr.ht" HEAD^
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!
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).