doc: fix typos

README.md

@@ -17,7 +17,7 @@
 
 `git-bug` is a bug tracker that:
 
-- **is fully embeded in git**: you only need your git repository to have a bug tracker
+- **is fully embedded in git**: you only need your git repository to have a bug tracker
 - **is distributed**: use your normal git remote to collaborate, push and pull your bugs!
 - **works offline**: in a plane or under the sea? Keep reading and writing bugs!
 - **prevents vendor lock-in**: your usual service is down or went bad? You already have a full backup.

commands/version.go

@@ -66,6 +66,6 @@ func init() {
 		"Only show the commit hash",
 	)
 	versionCmd.Flags().BoolVarP(&versionAll, "all", "a", false,
-		"Show all version informations",
+		"Show all version information",
 	)
 }

doc/jira_bridge.md

@@ -21,8 +21,8 @@ Hopefully the bridge will be able to enable synchronization of these soon.
 JIRA does not support user/personal access tokens. They have experimental
 3-legged oauth support but that requires an API token for the app configured
 by the server administrator. The only reliable authentication mechanism then is
-the username/password and session-token mechanims. We can aquire a session
-token programatically from the username/password but these are very short lived
+the username/password and session-token mechanism. We can acquire a session
+token programmatically from the username/password but these are very short lived
 (i.e. hours or less). As such the bridge currently requires an actual username
 and password as user credentials. It supports three options:
 
@@ -42,7 +42,7 @@ is configurable (in JIRA) per `issuetype` so the set might be different between
 "bug" and "story", for example.
 
 For now, the bridge only supports exporting issues as a single `issuetype`. If
-no configuration is provied, then the default is `"id": "10001"` which is
+no configuration is provided, then the default is `"id": "10001"` which is
 `"story"` in the default set of issue types.
 
 In addition to specifying the `issuetype` of issues created on export, the
@@ -100,7 +100,7 @@ with the `expand=changelog` query parameter. Unfortunately in this case the
 entire changelog is provided without paging.
 
 Each changelog entry is identified with a unique string `id`, but within a
-single changelog entry is a list of multilple fields that are modified. In other
+single changelog entry is a list of multiple fields that are modified. In other
 words a single "event" might atomically change multiple fields. As an example,
 when an issue is closed the `"status"` might change to `"closed"` and the
 `"resolution"` might change to `"fixed'`.
@@ -112,9 +112,9 @@ single JIRA change event might create more than one `git-bug` operation.
 However, when a `git-bug` operation is exported to JIRA it will only create a
 single changelog entry. Furthermore, when we modify JIRA issues over the REST
 API JIRA does not provide any information to associate that modification event
-with the changelog. We must, therefore, herustically match changelog entries
+with the changelog. We must, therefore, heuristically match changelog entries
 against operations that we performed in order to not import them as duplicate
-events. In order to assist in this matching proceess, the bridge will record the
+events. In order to assist in this matching process, the bridge will record the
 JIRA server time of the response to the `POST` (as reported by the `"Date"`
 response header). During import, we keep an iterator to the list of `git-bug`
 operations for the bug mapped to the Jira issue. As we walk the JIRA changelog,
@@ -134,13 +134,13 @@ then we treat that as a new comment edition. If we do not already have the
 comment imported, then we import an empty comment followed by a comment edition.
 
 Because comment editions are not uniquely identified in JIRA we identify them
-in `git-bug` by concatinating the JIRA issue `id` with the `updated` time of
+in `git-bug` by concatenating the JIRA issue `id` with the `updated` time of
 the edition.
 
 ### Workflow Validation (future)
 
 The long-term plan for the JIRA bridge is to download and store the workflow
-specifiations from the JIRA server. This includes the required metadata for
+specifications from the JIRA server. This includes the required metadata for
 issue creation, and the status state graph, and the set of required metadata for
 status transition.
 
@@ -170,7 +170,7 @@ configuration. You can set these options in your `.git/config` file:
 ### Issue Creation Defaults
 
 The format for this config entry is a JSON object containing fields you wish to
-set during issue creation when exproting bugs. If you provide a value for this
+set during issue creation when exporting bugs. If you provide a value for this
 configuration option, it must include at least the `"issuetype"` field, or
 the bridge will not be able to export any new issues.
 
@@ -250,7 +250,7 @@ Here is an example configuration with all optional fields set
 * [c70e22a] Implement additional query filters for import
 * [9ecefaa] Create JIRA mock and add REST unit tests
 * [67bf520] Create import/export integration tests
-* [1121826] Add unit tests for utilites
+* [1121826] Add unit tests for utilities
 * [0597088] Use OS keyring for credentials
 * [d3e8f79] Don't count on the `Total` value in paginations
 

doc/man/git-bug-version.1

@@ -28,7 +28,7 @@ Show git\-bug version information.
 
 .PP
 \fB\-a\fP, \fB\-\-all\fP[=false]
-	Show all version informations
+	Show all version information
 
 .PP
 \fB\-h\fP, \fB\-\-help\fP[=false]

doc/md/git-bug_version.md

@@ -15,7 +15,7 @@ git-bug version [flags]
 ```
   -n, --number   Only show the version number
   -c, --commit   Only show the commit hash
-  -a, --all      Show all version informations
+  -a, --all      Show all version information
   -h, --help     help for version
 ```
 

misc/powershell_completion/git-bug

@@ -226,8 +226,8 @@ Register-ArgumentCompleter -Native -CommandName 'git-bug' -ScriptBlock {
             [CompletionResult]::new('--number', 'number', [CompletionResultType]::ParameterName, 'Only show the version number')
             [CompletionResult]::new('-c', 'c', [CompletionResultType]::ParameterName, 'Only show the commit hash')
             [CompletionResult]::new('--commit', 'commit', [CompletionResultType]::ParameterName, 'Only show the commit hash')
-            [CompletionResult]::new('-a', 'a', [CompletionResultType]::ParameterName, 'Show all version informations')
-            [CompletionResult]::new('--all', 'all', [CompletionResultType]::ParameterName, 'Show all version informations')
+            [CompletionResult]::new('-a', 'a', [CompletionResultType]::ParameterName, 'Show all version information')
+            [CompletionResult]::new('--all', 'all', [CompletionResultType]::ParameterName, 'Show all version information')
             break
         }
         'git-bug;webui' {

misc/zsh_completion/git-bug

@@ -449,7 +449,7 @@ function _git-bug_version {
   _arguments \
     '(-n --number)'{-n,--number}'[Only show the version number]' \
     '(-c --commit)'{-c,--commit}'[Only show the commit hash]' \
-    '(-a --all)'{-a,--all}'[Show all version informations]'
+    '(-a --all)'{-a,--all}'[Show all version information]'
 }
 
 function _git-bug_webui {