You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
 
 

56 lines
2.7 KiB

commit c6eb147201c1d05afaadc5fd248b17be91f97331
Author: Bertrand Jacquin <bertrand@jacquin.bzh>
Date: Sat Oct 13 16:06:18 2018 +0100
DOC: Fix a few typos
these are mostly spelling mistakes, some of them might be candidate for
backporting as well.
(cherry picked from commit d5e4de8e5f99108e31dc7a23a0e91c4231e37974)
Signed-off-by: Willy Tarreau <w@1wt.eu>
diff --git a/CONTRIBUTING b/CONTRIBUTING
index b2c2b493..cd97e69b 100644
--- a/CONTRIBUTING
+++ b/CONTRIBUTING
@@ -309,7 +309,7 @@ do not think about them anymore after a few patches.
A good rule of thumb is that if your identifiers start to contain more than
3 words or more than 15 characters, they can become confusing. For function
names it's less important especially if these functions are rarely used or
- are used in a complex context where it is important to differenciate between
+ are used in a complex context where it is important to differentiate between
their multiple variants.
9) Unified diff only
@@ -318,7 +318,7 @@ do not think about them anymore after a few patches.
that you have committed your patch to a local branch, with an appropriate
subject line and a useful commit message explaining what the patch attempts
to do. It is not strictly required to use git, but what is strictly required
- is to have all these elements in the same mail, easily distinguishible, and
+ is to have all these elements in the same mail, easily distinguishable, and
a patch in "diff -up" format (which is also the format used by Git). This
means the "unified" diff format must be used exclusively, and with the
function name printed in the diff header of each block. That significantly
@@ -761,7 +761,7 @@ sent to the mailing list : haproxy@formilux.org and CCed to relevant subsystem
maintainers or authors of the modified files if their address appears at the
top of the file.
-Please don't send pull-requests, they are really unconvenient. First, a pull
+Please don't send pull-requests, they are really inconvenient. First, a pull
implies a merge operation and the code doesn't move fast enough to justify the
use of merges. Second, pull requests are not easily commented on by the
project's participants, contrary to e-mails where anyone is allowed to have an
diff --git a/include/types/connection.h b/include/types/connection.h
index 5e8af3e7..b9e46048 100644
--- a/include/types/connection.h
+++ b/include/types/connection.h
@@ -45,7 +45,7 @@ struct server;
struct pipe;
-/* A connection handle is how we differenciate two connections on the lower
+/* A connection handle is how we differentiate two connections on the lower
* layers. It usually is a file descriptor but can be a connection id.
*/
union conn_handle {