Git Guidelines | Organisation
Created by: LNJ2
Upstream pull requests and issues
- Don't mix multiple things in one commit. The same applies to codestyle cleanup.
- If a pull request or an issue does not get a response from its author in one month (when requiring more details), it is closed.
- If an issue is a duplicate, refer to the first one and close the later ones.
- People considering merging pull requests are not required to look anything up anywhere else than the pull request and its comments. If there is something blocking the merging of a pull request, the reason must be added as a comment to the pull request. This goes both ways: If you check a pull request to be mergeable, write a simple "+1" or "
👍" comment to it.
Upstream commit rules
- You can push something to upstream only if two members of the core team agree on it.
- Commit messages must start with a capital letter and be in the present tense (look at the commit log)
- Do not modify history older than 10 minutes
- Use rebase, not merge, to get linear history. (For a github pull request, this is easiest done by appending .patch to the pull request URL, wgetting it to your project directory and doing git am whatever.patch. Similarly for single commits.)
- Do not rush with anything, unless our users' data is about to be corrupted otherwise
A contributor is anyone who has made a pull request that has been merged, or succesfully sent a patch to be applied otherwise.
Core developers have special privileges and responsibilities compared to other contributors:
- Can vote for and against merging pull requests (Two for-votes are required for code to be mergeable upstream.)
- Has write access to the minetest team's repositories on github
Git Guidelines and Organisation in the Minetest Wiki.These rules are mostly copied from the open-source project "Minetest", see
@KaidanIM/core-devs: Do you all agree with these rules? We can discuss about them.
If everyone is satisfied, I will move this into the wiki.