Re: [TopGit PATCH] README: Fix spelling

> Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
>
> ---
>  README [m |   11  [32m+++++ [m [31m------ [m
>  1 files changed, 5 insertions(+), 6 deletions(-) [m
>
>  [1mdiff --git a/README b/README [m
>  [1mindex 5bfe3ee..9e291da 100644 [m
>  [1m--- a/README [m
>  [1m+++ b/README [m
>  [36m@@ -22,7 +22,7 @@ version control of patches (reordering of patches is not [m
>  version-controlled at all). But there are several disadvantages - [m
>  for one, these tools (especially StGIT) do not actually fit well [m
>  with plain Git at all: it is basically impossible to take advantage [m
>  [31m-of the index efectively when using StGIT. But more importantly, [m
>  [32m+ [m [32mof the index effectively when using StGIT. But more importantly, [m
>  these tools horribly fail in the face of distributed environment. [m
>  [m
>  TopGit has been designed around three main tenets: [m
>  [36m@@ -45,7 +45,7 @@ them. [m
>  [m
>  As mentioned above, the main intended use-case for TopGit is tracking [m
>  third-party patches, where each patch is effectively a single topic [m
>  [31m-branch.  In order to flexibly accomodate even complex scenarios when [m
>  [32m+ [m [32mbranch.  In order to flexibly accommodate even complex scenarios when [m
>  you track many patches where many are independent but some depend [m
>  on others, TopGit ignores the ancient Quilt heritage of patch series [m
>  and instead allows the patches to freely form graphs (DAGs just like [m
>  [36m@@ -222,7 +222,7 @@ tg create [m
>  [m
>        After `tg create`, you should insert the patch description [m
>        to the '.topmsg' file, which will already contain some [m
>  [31m-  pre-filled bits. You can set topgit.to, topgit.cc and topgit.bcc [m
>  [32m+ [m        [32mprefilled bits. You can set topgit.to, topgit.cc and topgit.bcc [m
>        configuration variables in order to have `tg create` [m
>        add these headers with given default values to '.topmsg'. [m
>  [m
>  [36m@@ -350,7 +350,7 @@ tg export [m
>        in the cleaned up history (corresponding basically exactly [m
>        to `tg patch` output for the topic branch). [m
>  [m
>  [31m-  The command has two posible outputs now - either a Git branch [m
>  [32m+ [m        [32mThe command has two possible outputs now - either a Git branch [m
>        with the collapsed history, or a quilt series in new directory. [m
>  [m
>        In case of producing collapsed history in new branch, [m
>  [36m@@ -455,7 +455,6 @@ tg update [m
>  [m
>        TODO: tg update -a for updating all topic branches [m
>  [m
>  [31m-TODO: tg depend for adding/removing dependencies smoothly [m
>  TODO: tg rename [m
>  [m
>  [m
>  [36m@@ -485,7 +484,7 @@ whatever Cc headers you choose or the post-three-dashes message. [m
>  When mailing out your patch, basically only few extra headers [m
>  mail headers are inserted and the patch itself is appended. [m
>  Thus, as your patches evolve, you can record nuances like whether [m
>  [31m-the paricular patch should have To-list/Cc-maintainer or vice [m
>  [32m+ [m [32mthe particular patch should have To-list/Cc-maintainer or vice [m
>  versa and similar nuances, if your project is into that. [m
>  From is prefilled from your current GIT_AUTHOR_IDENT, other headers [m
>  can be prefilled from various optional topgit.* config options. [m
> --
> tg: (f17218e..) jf/readme-update (depends on: master)
>