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. > Refs that are per working tree can still be accessed from another > diff --git a/Documentation/gitattributes.txt > b/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. > 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.
