-
Notifications
You must be signed in to change notification settings - Fork 596
Submitting Changes
(by pieter. pulled from a thread in the bugbase)
I don’t really care how you submit your work. You can use github to push your commits and then send me a pull message. I’d prefer to have an email rather than a push message, so that I can reply to that immediately. I don’t really like the github messaging part, because you can’t use your mail client.
You can also send me patches with your work (using, for example, git format-patch and git send-email). That way, I can reply to your commits in a mail message. This is useful if your patches need some modification.
I do prefer patches/branches that are clean: They don’t add or remove irrelevant parts of code, and the commits are logically ordered and have a clean commit message. This last parts includes commit subjects that fit on one line (less than 80 characters or so), and messages that are present tense rather than past tense (so “Add a one-line commit overview” instead of “Added a one-…”.
If you don’t do that, I’ll do it for you. Submitted patches will usually find their way in my own repository in the pu/initials/* branches, where I reformat them to my convention. If I react to your message with specific code improvements, it’s often useful to check my repository to see if I did some of the changes already. You can then build on that, or send a message like “I’m ok with your changes”
Here are a few notes on GitHub forks/branches:
- Please keep your branches clean if you want them merged at some point. That means:
- Descriptive commit-messages, with #bug if it is a fix
- Don’t be shy to rebase your forks, to fix intermediate commits. Also try to rebase it onto the tip of master from time to time.
- Please clean up stale branches or commits that were already fixed by someone else (or were denied inclusion).
Of course a fork belongs to you, and these “tips” are just if you want to make life easier for people having a look at the network-graph ;)