From 6dca640cb229f855927c3076cc482d3089ad63fc Mon Sep 17 00:00:00 2001 From: Marius Gedminas Date: Wed, 26 Aug 2015 08:13:20 +0300 Subject: [PATCH] Fix typo, remove redundant paragraph The bit about git rebase vs git merge is repeated in the paragraph below. The bit about test/integration is repeated in the paragraph above. (And the bit about aliasing git pull to git pull --rebase is unclear, since git's aliases cannot override builtin operations.) --- docsite/rst/community.rst | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/docsite/rst/community.rst b/docsite/rst/community.rst index 5cac69fe9a1..cebc1f91527 100644 --- a/docsite/rst/community.rst +++ b/docsite/rst/community.rst @@ -150,12 +150,9 @@ to modify a pull request later. When submitting patches, be sure to run the unit tests first “make tests” and always use, these are the same basic tests that will automatically run on Travis when creating the PR. There are more in depth tests in the tests/integration directory, classified as destructive and non_destructive, run these if they pertain to your modification. They are setup -with tags so you can run subsets, some of the tests requrie cloud credentials and will only run if they are provided. +with tags so you can run subsets, some of the tests require cloud credentials and will only run if they are provided. When adding new features of fixing bugs it would be nice to add new tests to avoid regressions. -Use “git rebase” vs “git merge” (aliasing git pull to git pull --rebase is a great idea) to avoid merge commits in -your submissions. There are also integration tests that can be run in the "test/integration" directory. - In order to keep the history clean and better audit incoming code, we will require resubmission of pull requests that contain merge commits. Use "git pull --rebase" vs "git pull" and "git rebase" vs "git merge". Also be sure to use topic branches to keep your additions on different branches, such that they won't pick up stray commits later.