diff options
author | Martin Michlmayr <tbm@cyrius.com> | 2020-06-16 21:29:18 +0800 |
---|---|---|
committer | Martin Michlmayr <tbm@cyrius.com> | 2020-06-16 21:32:03 +0800 |
commit | ff0ff86336cab667369f3d89aa1c603abffd23c6 (patch) | |
tree | 9ef230e2ca8a73b5d4ab85c6a34af7c59f3c9e78 /doc | |
parent | 6352d6aa2338f47cd8b60631dec5f4161d9d92ec (diff) | |
download | git-bug-ff0ff86336cab667369f3d89aa1c603abffd23c6.tar.gz |
doc: fix typos
Diffstat (limited to 'doc')
-rw-r--r-- | doc/jira_bridge.md | 20 | ||||
-rw-r--r-- | doc/man/git-bug-version.1 | 2 | ||||
-rw-r--r-- | doc/md/git-bug_version.md | 2 |
3 files changed, 12 insertions, 12 deletions
diff --git a/doc/jira_bridge.md b/doc/jira_bridge.md index df56bb2d..bf3c1a8b 100644 --- a/doc/jira_bridge.md +++ b/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 diff --git a/doc/man/git-bug-version.1 b/doc/man/git-bug-version.1 index 963e260e..07d4e0c5 100644 --- a/doc/man/git-bug-version.1 +++ b/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] diff --git a/doc/md/git-bug_version.md b/doc/md/git-bug_version.md index d10312ff..1f9e0fa7 100644 --- a/doc/md/git-bug_version.md +++ b/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 ``` |