On Fri, Apr 24, 2009 at 04:49:34PM +0200, Michael J Gruber wrote: > Replace sha1 by SHA-1 with the following exceptions: I seriously doubt that mentioning any particular hash algorithm (which is implementation detail) in so many places make much sense. IMHO, it would be much better to use some general name as hash-id or something. Besides, mentioning SHA-1 may lead to confusion. Take a look at the following text: > @@ -164,10 +164,10 @@ Using --cacheinfo or --info-only > current working directory. This is useful for minimum-checkout > merging. > > -To pretend you have a file with mode and sha1 at path, say: > +To pretend you have a file with mode and SHA-1 at path, say: > > ---------------- > -$ git update-index --cacheinfo mode sha1 path > +$ git update-index --cacheinfo mode SHA-1 path > ---------------- This is incorrect, and here is why: $ touch empty $ git hash-object empty e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 $ sha1sum empty da39a3ee5e6b4b0d3255bfef95601890afd80709 empty What should be given to git update-index is the hash produced by git hash-object and NOT SHA-1 of the file. (Yes, git hash-object does use SHA-1, but I seriously doubt that any Git user needs to know how git hash-object calculates the hash.) So, I hardly see how a mechanical replacement of sha1 with SHA-1 can be any improvement. While, at least, sha1 can be interpreted as SHA-1 based hash value returned by git-hash-object, your patch only enforces the misconception that we are dealing with SHA-1 of the file here. Dmitry -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html