From: Denton Liu <hidden> Date: 2021-02-23 06:40:23
Just a couple of documentation fixes that I noticed in passing today.
Nothing too controversial.
This branch is based on 'maint'.
Denton Liu (3):
i18n.txt: camel case and monospace "i18n.commitEncoding"
git-cat-file.txt: monospace args and placeholders
git-cat-file.txt: remove references to "sha1"
Documentation/git-cat-file.txt | 52 +++++++++++++++++-----------------
Documentation/i18n.txt | 2 +-
2 files changed, 27 insertions(+), 27 deletions(-)
--
2.30.0.478.g8a0d178c01
From: Denton Liu <hidden> Date: 2021-02-23 06:40:26
In 95791be750 (doc: camelCase the i18n config variables to improve
readability, 2017-07-17), the other i18n config variables were
camel cased. However, this one instance was missed.
Camel case and monospace "i18n.commitEncoding" so that it matches the
surrounding text.
Signed-off-by: Denton Liu <redacted>
---
Documentation/i18n.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
@@ -38,7 +38,7 @@ mind. a warning if the commit log message given to it does not look like a valid UTF-8 string, unless you explicitly say your project uses a legacy encoding. The way to say this is to- have i18n.commitencoding in `.git/config` file, like this:+ have `i18n.commitEncoding` in `.git/config` file, like this: + ------------ [i18n]
From: Denton Liu <hidden> Date: 2021-02-23 06:40:26
In modern documentation, args and placeholders are monospaced. Format
all remaining args and placeholders as monospace.
Signed-off-by: Denton Liu <redacted>
---
Documentation/git-cat-file.txt | 42 +++++++++++++++++-----------------
1 file changed, 21 insertions(+), 21 deletions(-)
@@ -35,42 +35,42 @@ OPTIONS -t:: Instead of the content, show the object type identified by- <object>.+ `<object>`. -s:: Instead of the content, show the object size identified by- <object>.+ `<object>`. -e::- Exit with zero status if <object> exists and is a valid- object. If <object> is of an invalid format exit with non-zero and+ Exit with zero status if `<object>` exists and is a valid+ object. If `<object>` is of an invalid format exit with non-zero and emits an error on stderr. -p::- Pretty-print the contents of <object> based on its type.+ Pretty-print the contents of `<object>` based on its type. <type>::- Typically this matches the real type of <object> but asking+ Typically this matches the real type of `<object>` but asking for a type that can trivially be dereferenced from the given- <object> is also permitted. An example is to ask for a- "tree" with <object> being a commit object that contains it,- or to ask for a "blob" with <object> being a tag object that+ `<object>` is also permitted. An example is to ask for a+ "tree" with `<object>` being a commit object that contains it,+ or to ask for a "blob" with `<object>` being a tag object that points at it. --textconv:: Show the content as transformed by a textconv filter. In this case,- <object> has to be of the form <tree-ish>:<path>, or :<path> in+ `<object>` has to be of the form `<tree-ish>:<path>`, or `:<path>` in order to apply the filter to the content recorded in the index at- <path>.+ `<path>`. --filters:: Show the content as converted by the filters configured in- the current working tree for the given <path> (i.e. smudge filters,- end-of-line conversion, etc). In this case, <object> has to be of- the form <tree-ish>:<path>, or :<path>.+ the current working tree for the given `<path>` (i.e. smudge filters,+ end-of-line conversion, etc). In this case, `<object>` has to be of+ the form `<tree-ish>:<path>`, or `:<path>`. --path=<path>::- For use with --textconv or --filters, to allow specifying an object+ For use with `--textconv` or `--filters`, to allow specifying an object name and a path separately, e.g. when it is difficult to figure out the revision from which the blob came.
@@ -115,7 +115,7 @@ OPTIONS repository. --allow-unknown-type::- Allow -s or -t to query broken/corrupt objects of unknown type.+ Allow `-s` or `-t` to query broken/corrupt objects of unknown type. --follow-symlinks:: With --batch or --batch-check, follow symlinks inside the
@@ -175,15 +175,15 @@ respectively print: OUTPUT -------If `-t` is specified, one of the <type>.+If `-t` is specified, one of the `<type>`.-If `-s` is specified, the size of the <object> in bytes.+If `-s` is specified, the size of the `<object>` in bytes.-If `-e` is specified, no output, unless the <object> is malformed.+If `-e` is specified, no output, unless the `<object>` is malformed.-If `-p` is specified, the contents of <object> are pretty-printed.+If `-p` is specified, the contents of `<object>` are pretty-printed.-If <type> is specified, the raw (though uncompressed) contents of the <object>+If `<type>` is specified, the raw (though uncompressed) contents of the `<object>` will be returned. BATCH OUTPUT
From: Denton Liu <hidden> Date: 2021-02-23 06:40:26
As part of the hash-transition, git can operate on more than just SHA-1
repositories. Replace "sha1"-specific documentation with hash-agnostic
terminology.
Signed-off-by: Denton Liu <redacted>
---
Documentation/git-cat-file.txt | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
@@ -200,7 +200,7 @@ object, with placeholders of the form `%(atom)` expanded, followed by a newline. The available atoms are: `objectname`::- The 40-hex object name of the object.+ The full hex representation of the object. `objecttype`:: The type of the object (the same as `cat-file -t` reports).
@@ -215,8 +215,8 @@ newline. The available atoms are: `deltabase`:: If the object is stored as a delta on-disk, this expands to the- 40-hex sha1 of the delta base object. Otherwise, expands to the- null sha1 (40 zeroes). See `CAVEATS` below.+ full hex representation of the delta base object. Otherwise, expands to the+ null OID (all zeroes). See `CAVEATS` below. `rest`:: If this atom is used in the output string, input lines are split
@@ -235,14 +235,14 @@ newline. For example, `--batch` without a custom format would produce: -------------<sha1> SP <type> SP <size> LF+<oid> SP <type> SP <size> LF <contents> LF ------------ Whereas `--batch-check='%(objectname) %(objecttype)'` would produce: -------------<sha1> SP <type> LF+<oid> SP <type> LF ------------ If a name is specified on stdin that cannot be resolved to an object in
From: Eric Sunshine <hidden> Date: 2021-02-23 06:45:55
On Tue, Feb 23, 2021 at 1:41 AM Denton Liu [off-list ref] wrote:
quoted hunk
In modern documentation, args and placeholders are monospaced. Format
all remaining args and placeholders as monospace.
Signed-off-by: Denton Liu <redacted>
---
@@ -115,7 +115,7 @@ OPTIONS --allow-unknown-type::- Allow -s or -t to query broken/corrupt objects of unknown type.+ Allow `-s` or `-t` to query broken/corrupt objects of unknown type. --follow-symlinks:: With --batch or --batch-check, follow symlinks inside the
From: Eric Sunshine <hidden> Date: 2021-02-23 06:49:45
On Tue, Feb 23, 2021 at 1:41 AM Denton Liu [off-list ref] wrote:
quoted hunk
As part of the hash-transition, git can operate on more than just SHA-1
repositories. Replace "sha1"-specific documentation with hash-agnostic
terminology.
Signed-off-by: Denton Liu <redacted>
---
@@ -200,7 +200,7 @@ object, with placeholders of the form `%(atom)` expanded, followed by a `objectname`::- The 40-hex object name of the object.+ The full hex representation of the object.
I find this new terminology confusing and ambiguous. To me, this seems
to be saying that it is a hex representation of the entire object
rather than a hex representation of the hash of the object. Perhaps
say either "hex representation of the hash of the object" or "hex
representation of the object ID"?
quoted hunk
@@ -215,8 +215,8 @@ newline. The available atoms are: `deltabase`:: If the object is stored as a delta on-disk, this expands to the- 40-hex sha1 of the delta base object. Otherwise, expands to the- null sha1 (40 zeroes). See `CAVEATS` below.+ full hex representation of the delta base object. Otherwise, expands to the+ null OID (all zeroes). See `CAVEATS` below.
Same issue. "hex representation of the delta base object" sounds
misleading. Should probably mention "hash of the" in there somewhere
or something.
From: Denton Liu <hidden> Date: 2021-02-23 07:00:15
In modern documentation, args, placeholders and filenames are
monospaced. Apply monospace formatting to these objects.
Signed-off-by: Denton Liu <redacted>
---
Thanks for catching the omission, Eric. I've gone through the
documentation with a fine-tooth comb and caught many more missing
instances.
Documentation/git-cat-file.txt | 56 +++++++++++++++++-----------------
1 file changed, 28 insertions(+), 28 deletions(-)
@@ -35,42 +35,42 @@ OPTIONS -t:: Instead of the content, show the object type identified by- <object>.+ `<object>`. -s:: Instead of the content, show the object size identified by- <object>.+ `<object>`. -e::- Exit with zero status if <object> exists and is a valid- object. If <object> is of an invalid format exit with non-zero and+ Exit with zero status if `<object>` exists and is a valid+ object. If `<object>` is of an invalid format exit with non-zero and emits an error on stderr. -p::- Pretty-print the contents of <object> based on its type.+ Pretty-print the contents of `<object>` based on its type. <type>::- Typically this matches the real type of <object> but asking+ Typically this matches the real type of `<object>` but asking for a type that can trivially be dereferenced from the given- <object> is also permitted. An example is to ask for a- "tree" with <object> being a commit object that contains it,- or to ask for a "blob" with <object> being a tag object that+ `<object>` is also permitted. An example is to ask for a+ "tree" with `<object>` being a commit object that contains it,+ or to ask for a "blob" with `<object>` being a tag object that points at it. --textconv:: Show the content as transformed by a textconv filter. In this case,- <object> has to be of the form <tree-ish>:<path>, or :<path> in+ `<object>` has to be of the form `<tree-ish>:<path>`, or `:<path>` in order to apply the filter to the content recorded in the index at- <path>.+ `<path>`. --filters:: Show the content as converted by the filters configured in- the current working tree for the given <path> (i.e. smudge filters,- end-of-line conversion, etc). In this case, <object> has to be of- the form <tree-ish>:<path>, or :<path>.+ the current working tree for the given `<path>` (i.e. smudge filters,+ end-of-line conversion, etc). In this case, `<object>` has to be of+ the form `<tree-ish>:<path>`, or `:<path>`. --path=<path>::- For use with --textconv or --filters, to allow specifying an object+ For use with `--textconv` or `--filters`, to allow specifying an object name and a path separately, e.g. when it is difficult to figure out the revision from which the blob came.
@@ -115,15 +115,15 @@ OPTIONS repository. --allow-unknown-type::- Allow -s or -t to query broken/corrupt objects of unknown type.+ Allow `-s` or `-t` to query broken/corrupt objects of unknown type. --follow-symlinks::- With --batch or --batch-check, follow symlinks inside the+ With `--batch` or `--batch-check`, follow symlinks inside the repository when requesting objects with extended SHA-1 expressions of the form tree-ish:path-in-tree. Instead of providing output about the link itself, provide output about the linked-to object. If a symlink points outside the- tree-ish (e.g. a link to /foo or a root-level link to ../foo),+ tree-ish (e.g. a link to `/foo` or a root-level link to `../foo`), the portion of the link which is outside the tree will be printed. +
@@ -175,15 +175,15 @@ respectively print: OUTPUT -------If `-t` is specified, one of the <type>.+If `-t` is specified, one of the `<type>`.-If `-s` is specified, the size of the <object> in bytes.+If `-s` is specified, the size of the `<object>` in bytes.-If `-e` is specified, no output, unless the <object> is malformed.+If `-e` is specified, no output, unless the `<object>` is malformed.-If `-p` is specified, the contents of <object> are pretty-printed.+If `-p` is specified, the contents of `<object>` are pretty-printed.-If <type> is specified, the raw (though uncompressed) contents of the <object>+If `<type>` is specified, the raw (though uncompressed) contents of the `<object>` will be returned. BATCH OUTPUT
@@ -258,7 +258,7 @@ If a name is specified that might refer to more than one object (an ambiguous sh <object> SP ambiguous LF -------------If --follow-symlinks is used, and a symlink in the repository points+If `--follow-symlinks` is used, and a symlink in the repository points outside the repository, then `cat-file` will ignore any custom format and print:
@@ -267,11 +267,11 @@ symlink SP <size> LF <symlink> LF -------------The symlink will either be absolute (beginning with a /), or relative-to the tree root. For instance, if dir/link points to ../../foo, then-<symlink> will be ../foo. <size> is the size of the symlink in bytes.+The symlink will either be absolute (beginning with a `/`), or relative+to the tree root. For instance, if dir/link points to `../../foo`, then+`<symlink>` will be `../foo`. `<size>` is the size of the symlink in bytes.-If --follow-symlinks is used, the following error messages will be+If `--follow-symlinks` is used, the following error messages will be displayed: ------------
From: Denton Liu <hidden> Date: 2021-02-23 07:19:06
As part of the hash-transition, git can operate on more than just SHA-1
repositories. Replace "sha1"-specific documentation with hash-agnostic
terminology.
Signed-off-by: Denton Liu <redacted>
---
Documentation/git-cat-file.txt | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
@@ -200,7 +200,7 @@ object, with placeholders of the form `%(atom)` expanded, followed by a newline. The available atoms are: `objectname`::- The 40-hex object name of the object.+ The full hex representation of the object ID of the object. `objecttype`:: The type of the object (the same as `cat-file -t` reports).
@@ -215,8 +215,9 @@ newline. The available atoms are: `deltabase`:: If the object is stored as a delta on-disk, this expands to the- 40-hex sha1 of the delta base object. Otherwise, expands to the- null sha1 (40 zeroes). See `CAVEATS` below.+ full hex representation of the object ID of the delta base+ object. Otherwise, expands to the null OID (all zeroes). See+ `CAVEATS` below. `rest`:: If this atom is used in the output string, input lines are split
@@ -235,14 +236,14 @@ newline. For example, `--batch` without a custom format would produce: -------------<sha1> SP <type> SP <size> LF+<oid> SP <type> SP <size> LF <contents> LF ------------ Whereas `--batch-check='%(objectname) %(objecttype)'` would produce: -------------<sha1> SP <type> LF+<oid> SP <type> LF ------------ If a name is specified on stdin that cannot be resolved to an object in
From: Junio C Hamano <hidden> Date: 2021-02-23 19:16:45
Denton Liu [off-list ref] writes:
In 95791be750 (doc: camelCase the i18n config variables to improve
readability, 2017-07-17), the other i18n config variables were
camel cased. However, this one instance was missed.
Camel case and monospace "i18n.commitEncoding" so that it matches the
surrounding text.
Signed-off-by: Denton Liu <redacted>
---
Documentation/i18n.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
@@ -38,7 +38,7 @@ mind. a warning if the commit log message given to it does not look like a valid UTF-8 string, unless you explicitly say your project uses a legacy encoding. The way to say this is to- have i18n.commitencoding in `.git/config` file, like this:+ have `i18n.commitEncoding` in `.git/config` file, like this: + ------------ [i18n]
Thanks, but whenever you noticed an issue like "Ah, here we used an
incorrect spelling i18n.commitencoding", please make it a habit to
see if we did exactly the same mistake elsewhere (you have been
working with Git long enough to know how cheap such a check is):
$ git grep -F -e i18n.commitencoding -- \
Documentation/ ':!Documentation/RelNotes/'
and you would have found three other instances.
This obviously does not have to be part of this miniseries, but I
wonder if we should have a list of all the configuration variables
in one place that we can use to record the canonical spelling of
these variables. As
$ git grep -h -E -i \
-e '^[a-z][-a-z0-9]*\.[a-z][-a-z0-9]*::' \
-e '^[a-z][-a-z0-9]*\.(\*|<?[a-z][-a-z0-9]*>?)\.(\*|<?[a-z][-a-z0-9]*>?)::' \
Documentation/config
gives many hits with camelCased names, it might be a good place to
start.
Pretending that the above gives a good "canonical list" (it does not
yet, if you look at the hits), I got curious how far we can go.
Massaging the output from the above into config-variables.lst
$ ... above command ... |
sed -e 's/::$//' |
sort -u >config-variables.lst
and then to extract use of these tokens in the main part of the
documentation like this:
$ git grep -h -o -i -F -f config-variables.lst -- \
Documentation/ ':!Documentation/RelNotes/' |
sort -u >config-usage.lst
gives us something we can compare with the "canonical" usage list.
$ comm -3 config-usage.lst config-variables.lst
blame.blankboundary
core.excludesfile
core.filemode
core.gitproxy
core.ignorestat
core.logallrefupdates
core.repositoryformatversion
core.trustCtime
http.sslverify
http.sslversion
i18n.commitencoding
push.pushoption
remote.<name>.partialCloneFilter
remote.pushdefault
repack.UseDeltaBaseOffset
sendemail.aliasesfile
showbranch.default
transfer.hiderefs
uploadArchive.allowUnreachable
Some of them may be false hits, some may be showing that the copy in
Documentation/config/ are spelled in all lowercase, but the majority
of the hits above seem to be genuine errors similar to what you fixed
in your patch.
Thanks.
From: Denton Liu <hidden> Date: 2021-03-04 00:22:41
As part of the hash-transition, git can operate on more than just SHA-1
repositories. Replace "sha1"-specific documentation with hash-agnostic
terminology.
Signed-off-by: Denton Liu <redacted>
---
Documentation/git-cat-file.txt | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
@@ -200,7 +200,7 @@ object, with placeholders of the form `%(atom)` expanded, followed by a newline. The available atoms are: `objectname`::- The 40-hex object name of the object.+ The full hex representation of the object name. `objecttype`:: The type of the object (the same as `cat-file -t` reports).
@@ -215,8 +215,9 @@ newline. The available atoms are: `deltabase`:: If the object is stored as a delta on-disk, this expands to the- 40-hex sha1 of the delta base object. Otherwise, expands to the- null sha1 (40 zeroes). See `CAVEATS` below.+ full hex representation of the delta base object name.+ Otherwise, expands to the null OID (all zeroes). See `CAVEATS`+ below. `rest`:: If this atom is used in the output string, input lines are split
@@ -235,14 +236,14 @@ newline. For example, `--batch` without a custom format would produce: -------------<sha1> SP <type> SP <size> LF+<oid> SP <type> SP <size> LF <contents> LF ------------ Whereas `--batch-check='%(objectname) %(objecttype)'` would produce: -------------<sha1> SP <type> LF+<oid> SP <type> LF ------------ If a name is specified on stdin that cannot be resolved to an object in
From: Denton Liu <hidden> Date: 2021-03-04 00:22:47
A couple of fixes that I've noticed in passing.
Changes since v1:
* Drop 'i18n.txt: camel case and monospace "i18n.commitEncoding"' (it's already
merged to 'master')
* Change "object ID of the object" to "object name"
Denton Liu (2):
git-cat-file.txt: monospace args, placeholders and filenames
git-cat-file.txt: remove references to "sha1"
Documentation/git-cat-file.txt | 67 +++++++++++++++++-----------------
1 file changed, 34 insertions(+), 33 deletions(-)
Range-diff against v1:
1: cc48b12516 < -: ---------- i18n.txt: camel case and monospace "i18n.commitEncoding"
2: 7dab69ce23 = 1: 6d044cf540 git-cat-file.txt: monospace args, placeholders and filenames
3: 4030a678b9 ! 2: 1b57fdad97 git-cat-file.txt: remove references to "sha1"
@@ Documentation/git-cat-file.txt: object, with placeholders of the form `%(atom)`
`objectname`::
- The 40-hex object name of the object.
-+ The full hex representation of the object ID of the object.
++ The full hex representation of the object name.
`objecttype`::
The type of the object (the same as `cat-file -t` reports).
@@ Documentation/git-cat-file.txt: newline. The available atoms are:
If the object is stored as a delta on-disk, this expands to the
- 40-hex sha1 of the delta base object. Otherwise, expands to the
- null sha1 (40 zeroes). See `CAVEATS` below.
-+ full hex representation of the object ID of the delta base
-+ object. Otherwise, expands to the null OID (all zeroes). See
-+ `CAVEATS` below.
++ full hex representation of the delta base object name.
++ Otherwise, expands to the null OID (all zeroes). See `CAVEATS`
++ below.
`rest`::
If this atom is used in the output string, input lines are split
--
2.30.1.823.g0a3b79fd18
From: Denton Liu <hidden> Date: 2021-03-04 00:22:56
In modern documentation, args, placeholders and filenames are
monospaced. Apply monospace formatting to these objects.
Signed-off-by: Denton Liu <redacted>
---
Documentation/git-cat-file.txt | 56 +++++++++++++++++-----------------
1 file changed, 28 insertions(+), 28 deletions(-)
@@ -35,42 +35,42 @@ OPTIONS -t:: Instead of the content, show the object type identified by- <object>.+ `<object>`. -s:: Instead of the content, show the object size identified by- <object>.+ `<object>`. -e::- Exit with zero status if <object> exists and is a valid- object. If <object> is of an invalid format exit with non-zero and+ Exit with zero status if `<object>` exists and is a valid+ object. If `<object>` is of an invalid format exit with non-zero and emits an error on stderr. -p::- Pretty-print the contents of <object> based on its type.+ Pretty-print the contents of `<object>` based on its type. <type>::- Typically this matches the real type of <object> but asking+ Typically this matches the real type of `<object>` but asking for a type that can trivially be dereferenced from the given- <object> is also permitted. An example is to ask for a- "tree" with <object> being a commit object that contains it,- or to ask for a "blob" with <object> being a tag object that+ `<object>` is also permitted. An example is to ask for a+ "tree" with `<object>` being a commit object that contains it,+ or to ask for a "blob" with `<object>` being a tag object that points at it. --textconv:: Show the content as transformed by a textconv filter. In this case,- <object> has to be of the form <tree-ish>:<path>, or :<path> in+ `<object>` has to be of the form `<tree-ish>:<path>`, or `:<path>` in order to apply the filter to the content recorded in the index at- <path>.+ `<path>`. --filters:: Show the content as converted by the filters configured in- the current working tree for the given <path> (i.e. smudge filters,- end-of-line conversion, etc). In this case, <object> has to be of- the form <tree-ish>:<path>, or :<path>.+ the current working tree for the given `<path>` (i.e. smudge filters,+ end-of-line conversion, etc). In this case, `<object>` has to be of+ the form `<tree-ish>:<path>`, or `:<path>`. --path=<path>::- For use with --textconv or --filters, to allow specifying an object+ For use with `--textconv` or `--filters`, to allow specifying an object name and a path separately, e.g. when it is difficult to figure out the revision from which the blob came.
@@ -115,15 +115,15 @@ OPTIONS repository. --allow-unknown-type::- Allow -s or -t to query broken/corrupt objects of unknown type.+ Allow `-s` or `-t` to query broken/corrupt objects of unknown type. --follow-symlinks::- With --batch or --batch-check, follow symlinks inside the+ With `--batch` or `--batch-check`, follow symlinks inside the repository when requesting objects with extended SHA-1 expressions of the form tree-ish:path-in-tree. Instead of providing output about the link itself, provide output about the linked-to object. If a symlink points outside the- tree-ish (e.g. a link to /foo or a root-level link to ../foo),+ tree-ish (e.g. a link to `/foo` or a root-level link to `../foo`), the portion of the link which is outside the tree will be printed. +
@@ -175,15 +175,15 @@ respectively print: OUTPUT -------If `-t` is specified, one of the <type>.+If `-t` is specified, one of the `<type>`.-If `-s` is specified, the size of the <object> in bytes.+If `-s` is specified, the size of the `<object>` in bytes.-If `-e` is specified, no output, unless the <object> is malformed.+If `-e` is specified, no output, unless the `<object>` is malformed.-If `-p` is specified, the contents of <object> are pretty-printed.+If `-p` is specified, the contents of `<object>` are pretty-printed.-If <type> is specified, the raw (though uncompressed) contents of the <object>+If `<type>` is specified, the raw (though uncompressed) contents of the `<object>` will be returned. BATCH OUTPUT
@@ -258,7 +258,7 @@ If a name is specified that might refer to more than one object (an ambiguous sh <object> SP ambiguous LF -------------If --follow-symlinks is used, and a symlink in the repository points+If `--follow-symlinks` is used, and a symlink in the repository points outside the repository, then `cat-file` will ignore any custom format and print:
@@ -267,11 +267,11 @@ symlink SP <size> LF <symlink> LF -------------The symlink will either be absolute (beginning with a /), or relative-to the tree root. For instance, if dir/link points to ../../foo, then-<symlink> will be ../foo. <size> is the size of the symlink in bytes.+The symlink will either be absolute (beginning with a `/`), or relative+to the tree root. For instance, if dir/link points to `../../foo`, then+`<symlink>` will be `../foo`. `<size>` is the size of the symlink in bytes.-If --follow-symlinks is used, the following error messages will be+If `--follow-symlinks` is used, the following error messages will be displayed: ------------