| Message ID | 4030a678b923ca6a49b4e5bc6f0cdf4cf6ae7037.1614064618.git.liu.denton@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] git-cat-file.txt: remove references to "sha1" | expand |
Denton Liu <liu.denton@gmail.com> writes: > `objectname`:: > - The 40-hex object name of the object. > + The full hex representation of the object ID of the object. While I agree that it is a good idea to move away from an explicit mention of "40", I do not see why we would want to explain "object name" not as "object name" but as "object ID". IOW, s/ID/name/. > @@ -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. Likewise. Documentation/glossary-content.txt says "object name" is the canonical term, with "object identifier", "hash" etc. as its synonyms. > @@ -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 > ------------ These look good. Thanks.
diff --git a/Documentation/git-cat-file.txt b/Documentation/git-cat-file.txt index a1c37a9e81..c404a9aae8 100644 --- a/Documentation/git-cat-file.txt +++ b/Documentation/git-cat-file.txt @@ -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
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 <liu.denton@gmail.com> --- Documentation/git-cat-file.txt | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)