Contributing to Neovim
If you want to help but don't know where to start, here are some low-risk/isolated tasks:
- Help us review pull requests!
- Merge a Vim patch.
- Try a complexity:low issue.
- Fix clang-scan or coverity warnings.
- Check the FAQ.
- Search existing issues (including closed!)
- Update Neovim to the latest version to see if your problem persists.
- If you're using a plugin manager, comment out your plugins, then add them back in one by one, to narrow down the cause of the issue.
- Crash reports which include a stacktrace are 10x more valuable.
- Bisecting to the cause of a regression often leads to an immediate fix.
Pull requests ("PRs")
- To avoid duplicate work, you may want to create a
[WIP]pull request so that others know what you are working on.
- Avoid cosmetic changes to unrelated files in the same commit: extra noise makes reviews more difficult.
- Use a feature branch instead of the master branch.
- Rebase your feature branch onto (upstream) master before opening the PR.
- After addressing the review comments, it's fine to rebase and force-push to your review.
- Try to tidy your history: combine related commits with interactive rebasing, separate monolithic commits, etc.
Stages: WIP, RFC, RDY
Pull requests have three stages:
[WIP] (Work In Progress),
For Comment) and
- Untagged PRs are assumed to be
[RFC], i.e. you are requesting a review.
[WIP]to the PR title if you are not requesting feedback and the work is still in flux.
[RDY]to the PR title if you are done with the PR and are only waiting on it to be merged.
For example, a typical workflow is:
- You open a
[WIP]PR where the work is not ready for feedback, you just want to let others know what you are doing.
- Once the PR is ready for review, you replace
[WIP]in the title with
[RFC]. You may add fix up commits to address issues that come up during review.
- Once the PR is ready for merging, you rebase/squash your work appropriately and
[RFC]in the title with
Follow commit message hygiene to make reviews easier and to make the VCS/git logs more valuable.
- Try to keep the first line under 72 characters.
- Prefix the commit subject with a scope:
- For commits that contain only style/lint changes, a single-word subject
line is preferred:
- For commits that contain only style/lint changes, a single-word subject line is preferred:
- A blank line must separate the subject from the description.
- Use the imperative voice: "Fix bug" rather than "Fixed bug" or "Fixes bug."
Automated builds (CI)
- CI builds are compiled with
-Werror, so if your PR introduces any compiler warnings, the build will fail.
- If any tests fail, the build will fail. See Building Neovim#running-tests to run tests locally. Passing locally doesn't guarantee passing the CI build, because of the different compilers and platforms tested against.
- CI runs ASan and other analyzers. To run valgrind locally:
VALGRIND=1 make test
lintbuild (#3174) checks modified lines and their immediate neighbors. This is to encourage incrementally updating the legacy style to meet our style guidelines.
- A single word (
style) is sufficient as the subject line of a commit that contains only style changes.
- A single word (
- How to investigate QuickBuild failures
Coverity runs against the master build. If you want to view the defects, just request access at the Contributor level. An Admin will grant you permission.
Use this commit-message format for coverity fixes:
coverity/<id>: <description of what fixed the defect>
<id> is the Coverity ID (CID). For example see #804.
To help review pull requests, start with this checklist.
hub checkout https://github.com/neovim/neovim/pull/1820
git log -p master..FETCH_HEAD to list all
commits in the feature branch which aren't in the
shows each commit's diff. To show the whole surrounding function of a change
as context, use the
-W argument as well.