Re: [PATCH] doc: fix typos in man pages
From: Junio C Hamano <hidden>
Date: 2019-03-18 07:09:07
Alexander Blesius [off-list ref] writes:
quoted hunk ↗ jump to hunk
Signed-off-by: Alexander Blesius <redacted> --- Documentation/git-worktree.txt | 4 ++-- Documentation/gitattributes.txt | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-)diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt index cb86318f3e..fa5ec7a5dc 100644 --- a/Documentation/git-worktree.txt +++ b/Documentation/git-worktree.txt@@ -213,8 +213,8 @@ refs of one working tree from another. In general, all pseudo refs are per working tree and all refs starting with "refs/" are shared. Pseudo refs are ones like HEAD which are -directly under GIT_DIR instead of inside GIT_DIR/refs. There are one -exception to this: refs inside refs/bisect and refs/worktree is not +directly under GIT_DIR instead of inside GIT_DIR/refs. There is one +exception to this: refs inside refs/bisect and refs/worktree are not shared. Refs that are per working tree can still be accessed from anotherdiff --git a/Documentation/gitattributes.txtb/Documentation/gitattributes.txt
Oops. Like-wrapped patch. Please make sure your MUA does not corrupt your patch before sending a patch the next time. With a small change like this, I can manually type the change and pretend as if I applied the patch, so no need to resend this particular one. Thanks again.
quoted hunk ↗ jump to hunk
index 9b41f81c06..908d9a3009 100644--- a/Documentation/gitattributes.txt +++ b/Documentation/gitattributes.txt@@ -314,8 +314,8 @@ stored as UTF-8 internally. A client without`working-tree-encoding` support will checkout `foo.ps1` as UTF-8 encoded file. This will typically cause trouble for the users of this file. + -If a Git client, that does not support the `working-tree-encoding` -attribute, adds a new file `bar.ps1`, then `bar.ps1` will be +If a Git client that does not support the `working-tree-encoding` +attribute adds a new file `bar.ps1`, then `bar.ps1` will be stored "as-is" internally (in this example probably as UTF-16). A client with `working-tree-encoding` support will interpret the internal contents as UTF-8 and try to convert it to UTF-16 on checkout.