Everyone is welcome to submit any patches, bug reports,
comments, questions, ideas related to projects hosted at
git.ignore.pl by sending an e-mail to:
patches@ignore.pl
The list is moderated. Accepted messages will appear at:
patches.ignore.pl
Before sending an e-mail, see:
- Agreement
- About real names
- General recommendations
- Instruction aka "How to send patches"
- Why not X?
Agreement
By sending an e-mail to the mailing list, you:
- Agree for your messages to appear in the web archive,
- Agree for your commits to be merged and maintained within the
repository,
- Agree for your commits to appear in the web git interface at
git.ignore.pl,
- Declare that you have read and understood any additional
project-related contributing information and/or rules,
- Declare the patches you send are your original work and/or you hold
all the necessary copyrights for it to be published here,
- Declare that, if patches are based upon other work, to the best extent
of your knowledge, you are allowed to modify and republish them,
- Declare that, if patches were provided to you by third party,
that third party declared the same agreement and statements as are
written here,
- Declare the patches are made with the goodwill towards the project
and the community.
Projects may supersede these general agreement with, for example,
Developer Certificate of
Origin along with a sign-off mechanism (be it in commit messages or
another way).
About real names
At the moment, unless project specifies otherwise, use of a strict
"real name" policy is not required. Sign-offs with nicknames or
pseudonyms are acceptable the same way sign-offs with real names are.
It'd be best to know who is who. If you plan to be a long-term
contributor, consider sending the maintainers contact information as a
lifeguard in case of legal troubles. It'd be best if we could get to
know one another, drink together, and know who is behind the nickname,
without worrying about legal stuff, but it's not always possible.
Please do inform maintainers in case you are available to go out drinking.
General recommendations
For patches:
- Send messages in text/plain and/or flowed formats.
- Wrap commits and messages with fmt(1) or after 72 columns.
- Read any documentation on contributing to the specific project if any.
- Even if not required, consider adding a "Signed-off-by:" trailer/tag
to your commit message.
- Use git-send-email(1) for sending patches.
- Use
[PATCH project] or [PATCH project
0/5] subject prefix, some examples:
[PATCH datever] Use author time instead of committer time
[PATCH starshatter 0/5] Refactors around Color
[PATCH starshatter 1/5] Removed Video use in Color
[PATCH starshatter 2/5] Removed Texture and texture_palette from Color
[PATCH starshatter 3/5] Removed unused Color::SaveShadeTable
[PATCH starshatter 4/5] Removed static palette and table from Color interface
[PATCH starshatter 5/5] Cleaned-up ColorPalette interface
- Prefer to send a "cover-letter" for patch series (0/5 in the example
above).
- Prefer commit message style similar to the one used in the repository
you send the patch to.
- Prefer to add an explanation, reasoning, etc in the commit after
short title, for example:
Query git log only if needed
Porcelain git log --follow with sequential popens takes time. It's not
much, but it could definitely grow over time. This is one way to cut
it by some.
- Don't feel stiff. If something's not right, don't worry, I'll look
at what you send me nonetheless. If you don't know how to send patches,
just attach a diff, a patch, try to put it in the message, or look below
at Instruction. I'll figure out how to read them.
- Feel free to
[RFC https://git.example.com/random/project]
some changes to start discussion about unrelated projects that
you want someone to comment on.
- If there is no copyright notices in the repository, let me know.
We can discuss the licensing of the repository and the license for
your changes. I default to GPLv3-or-later if I need to put something.
For discussions, bug reports, others:
Instruction
Let's say you want to send the latest commit, the preferable method is:
$ git send-email --to=patches@ignore.pl --subject-prefix="PATCH repo" HEAD^
If not configured you may need to set SMTP server, log in, and so on.
See git-send-email(1) for details, it's a good manual. You may
want to tweak CCs to include maintainers and authors of the affected code.
Now, what if you must use something like Mozilla Thunderbird for
whatever reason?
First, ensure that the mail you send is plain text. This is the most
important part, find it in application settings and enforce plain text.
Test it on yourself by sending an email and the going into e-mail's
source. Once this is done:
- Generate a patch (you may do it even in a send-email workflow to
run some checks on it):
$ git format-patch --subject-prefix="PATCH repo" HEAD^
0001-example-commit.patch
- Open it in a text editor.
- Copy the Subject as your subject:
From 557a61e1f0d87f706779b0eb18dfcd11e60dfb5f Mon Sep 17 00:00:00 2001
From: John Doe <john.doe@example.com>
Date: Wed, 27 Sep 2025 00:00:00 +0200
Subject: [PATCH repo] example commit
This is an example commit showcasing an exported patch.
- Copy everything excluding first blank line. Include the first
--- and everything below:
Subject: [PATCH repo] example commit
This is an example commit showcasing an exported patch.
If you don't have a longer commit message, then your patch will start with
"---". If so, start copying with it.
Signed-off-by: John Doe <john.doe@example.com>
---
Makefile | 2 +-
1 file changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index eff7220..d6cda36 100644
--- a/Makefile
+++ b/Makefile
@@ -16,7 +16,7 @@ install:
uninstall:
rm -rf $(DESTDIR)$(LUA_LMOD)/example
- rm -f $(DESTIR)$(BINDIR)/example
+ rm -f $(DESTDIR)$(BINDIR)/example
test:
busted
--
2.51.0
- Send it!
Why not github.com?
Primarily because of my preference. I love e-mail git workflow and
I find it very comfortable to use. I think this workflow works, is
reliable, and I don't see a reason to change it entirely to something
else. I'd want to encourage people to use it and not be afraid of it.
I dislike big companies.
Yes, I heard about github.com, gitlab.com, sr.ht, codeberg.org,
and/or bitbucket.org. At least include sourceforge.net in the list!