Alexander Blesius <alexander+git@xxxxxxxxxx> writes:
> Signed-off-by: Alexander Blesius <alexander+git@xxxxxxxxxx>
> ---
> 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.
Perhaps bisect is one and worktree is the other, and that made them
two things (plural) in the author's mind. But the single exception
is about these two hierarchies, so "is" is correct ;-)
> Refs that are per working tree can still be accessed from another
> diff --git a/Documentation/gitattributes.txt
> b/Documentation/gitattributes.txt
> 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
Or s/that/which/. I am not sure which one gives us a cleaner
result.
If a new file `bar.ps1` is added by a Git client that does not
understand `working-tree-encoding` attribute, then ...
is how I may write it, though. I dunno. Let's take yours at least
for now and let others complain if they care deeply about it.
> 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.
Thanks.
