Dirk Gouders <dirk@xxxxxxxxxxx> writes: >> I'd rather not to waste readers' attention to historical wart. > > Yes, but -- I should have mentioned it -- the document itself suggests > to read the initial commit. Ahh, yes, we'd need to hedge that part. Good thinking. I am still not sure if the first hunk below is a good idea or it is too much detail. The second hunk may be worth doing. Thanks. Documentation/user-manual.txt | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git c/Documentation/user-manual.txt w/Documentation/user-manual.txt index 6433903491..1027055784 100644 --- c/Documentation/user-manual.txt +++ w/Documentation/user-manual.txt @@ -4093,7 +4093,8 @@ that not only specifies their type, but also provides size information about the data in the object. It's worth noting that the SHA-1 hash that is used to name the object is the hash of the original data plus this header, so `sha1sum` 'file' does not match the object name -for 'file'. +for 'file' (the earliest versions of Git hashed slightly differently +but the conclusion is still the same). As a result, the general consistency of an object can always be tested independently of the contents or the type of the object: all objects can @@ -4123,7 +4124,8 @@ $ git switch --detach e83c5163 ---------------------------------------------------- The initial revision lays the foundation for almost everything Git has -today, but is small enough to read in one sitting. +today (even though details may differ in a few places), but is small +enough to read in one sitting. Note that terminology has changed since that revision. For example, the README in that revision uses the word "changeset" to describe what we
