Documentation: add setup instructions for Travis CI
Also change UK english "behaviour" to US english "behavior".
Signed-off-by: Lars Schneider <larsxschneider@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
maint
Lars Schneider9 years agocommitted byJunio C Hamano
@ -61,23 +61,28 @@ Make sure that you have tests for the bug you are fixing. See
@@ -61,23 +61,28 @@ Make sure that you have tests for the bug you are fixing. See
t/README for guidance.
When adding a new feature, make sure that you have new tests to show
the feature triggers the new behaviour when it should, and to show the
feature does not trigger when it shouldn't. Also make sure that the
test suite passes after your commit. Do not forget to update the
documentation to describe the updated behaviour.
Speaking of the documentation, it is currently a liberal mixture of US
and UK English norms for spelling and grammar, which is somewhat
unfortunate. A huge patch that touches the files all over the place
only to correct the inconsistency is not welcome, though. Potential
clashes with other changes that can result from such a patch are not
worth it. We prefer to gradually reconcile the inconsistencies in
favor of US English, with small and easily digestible patches, as a
side effect of doing some other real work in the vicinity (e.g.
rewriting a paragraph for clarity, while turning en_UK spelling to
en_US). Obvious typographical fixes are much more welcomed ("teh ->
"the"), preferably submitted as independent patches separate from
other documentation changes.
the feature triggers the new behavior when it should, and to show the
feature does not trigger when it shouldn't. After any code change, make
sure that the entire test suite passes.
If you have an account at GitHub (and you can get one for free to work
on open source projects), you can use their Travis CI integration to
test your changes on Linux, Mac (and hopefully soon Windows). See
GitHub-Travis CI hints section for details.
Do not forget to update the documentation to describe the updated
behavior and make sure that the resulting documentation set formats
well. It is currently a liberal mixture of US and UK English norms for
spelling and grammar, which is somewhat unfortunate. A huge patch that
touches the files all over the place only to correct the inconsistency
is not welcome, though. Potential clashes with other changes that can
result from such a patch are not worth it. We prefer to gradually
reconcile the inconsistencies in favor of US English, with small and
easily digestible patches, as a side effect of doing some other real
work in the vicinity (e.g. rewriting a paragraph for clarity, while
turning en_UK spelling to en_US). Obvious typographical fixes are much
more welcomed ("teh -> "the"), preferably submitted as independent
patches separate from other documentation changes.
Oh, another thing. We are picky about whitespaces. Make sure your
changes do not trigger errors with the sample pre-commit hook shipped
@ -370,6 +375,47 @@ Know the status of your patch after submission
@@ -370,6 +375,47 @@ Know the status of your patch after submission
entitled "What's cooking in git.git" and "What's in git.git" giving