Git Workflow

This page describes contributor and maintainer workflows for contributing patches using git.

Contributors

Fork and branch the relevant MyPaint repository
Commit changes using git
Create a pull request or draft pull request on the relevant MyPaint repository and branch.
A project maintainer will review your code and accept it, reject it, or make suggestions.
- If your pull request is incompatible with the development branch, we’ll guide you through rebasing or force pushing it.

Branches

Use separate branches per each fix or enhancement.
- This helps the maintainers keep understand how the pull request’s topic relates to changes in the code.
Split commits logically, either by being selective with files, or staging interactively.

Dead Code

Dead code, also known as commented-out code quickly becomes out of date and misleading. Do not include any in your pull request.

Writing Commit Messages

Each commit you contribute should have a good commit message. Here’s an example of a good MyPaint commit message:

Splarp view: fix rotation direction.

The direction of rotation for the splarp was incorrect.
When the user turned it clockwise, it went anticlockwise
and vice versa. This commit swaps the two directions.

Closes mypaint/mypaint#666.
Makes mypaint/libmypaint#999 a little better.

Formatting Commit Messages

Firstly, this is a good read on how commit messages work.
Format commits so that each line is less than 72 characters long.
Make sure that the summary line is 50 characters or less.
Separate the summary line from the body with a blank line.

Structure of a Commit Message

Summary line: <thing-you-changed>: <what-you-did-to-it>. Not every commit summary follows the convention, but many do.
If a commit fixes or refers to an issue, please refer to the issue by number, either as mypaint/mypaint#nnn or as mypaint/libmypaint#nnn.
- This issue reference notation will allow the main repository to receive mentions from your forked repository.
If a commit fixes an issue, write a message that automatically closes the issue when merged.

Maintainers

Git Branches

---
config:
    gitGraph:
        rotateCommitLabel: false
---
gitGraph TB:
    commit id:"initial state"
    branch release
    checkout release
    cherry-pick id: "initial state" tag: "v1.2.3-beta"
    checkout main
    branch feature-z
    checkout feature-z
    commit id:"z: added..."
    checkout main
    commit id:"merged stable feature x"
    checkout release
    cherry-pick id: "merged stable feature x"
    checkout main
    commit id:"merged experimental feature y"
    checkout feature-z
    commit id:"z: fixed..."
    commit id:"z: cleaned up..."
    checkout main
    merge feature-z id:"merged feature z"
    checkout release
    cherry-pick id: "merged feature z" parent: "z: cleaned up..."
    checkout main
    commit id: "updated translations"
    checkout release
    cherry-pick id: "updated translations" tag: "v1.2.3-rc-1"
    checkout main
    commit id: "hotfix..."
    checkout release
    cherry-pick id: "hotfix..." tag:"v1.2.3"

Pull Requests

Why Pull Requests?

Pull requests are a good organisational unit that ensures contributed code that isn’t merged won’t be forgotten. On our side, it makes it easier to review changes you make.

Merging Pull Requests

Check licenses
Merge to development or a feature branch. Do not merge to main unless releasing a new version.
Review the files changed.
Test the changes locally.

Unit tests

Please run the doctests before committing new code.

# apt-get install python-nose
$ python setup.py nosetests

We have some heavier conformance tests for the C++ parts too. These take longer to run.

$ python setup.py test

You should write doctests for important new Python code. Please consider writing tests in the tests folder too, if you make any changes to the C++ extension or libmypaint.

To cleanup between unit tests you may want to run:

$ python setup.py clean --all
$ rm -vf lib/*_wrap.c*

Changelog

Notable changes to MyPaint should be referenced in MyPaint’s changelog.