On Apr 25, 2009, at 3:24 PM, Felipe Contreras wrote:
On Sat, Apr 25, 2009 at 10:16 PM, Michael Witten
<mfwitten@xxxxxxxxx> wrote:
On Sat, Apr 25, 2009 at 13:55, Daniel Barkalow
<barkalow@xxxxxxxxxxxx> wrote:
On Fri, 24 Apr 2009, Michael Witten wrote:
And the term is already in use for this particular case,
and it doesn't mean anything else at all (since, of course, the
crypto
thing is "SHA-1", not "sha1"), and it's short (which is
important for
making it easy to look at usage help).
What happens when SHA-1 is shown to be broken or there is a better
alternative? Then we'll see "sha1 for historical reasons"... bleh!
Why do you think SHA-1 has anything to do with it?
Well, it's named sha1.
Git's sha1s could just
as easily be 160 bits of a SHA-256 hash and there wouldn't be any
user-visible difference. The term doesn't imply any particular
significant
connection to a particular algorithm.
Then give it a generic name like 'hash'.
For most purposes in the documentation sha1's are used as ids, so why
don't use "id" instead? Like 'commit id'. The fact that the id is also
a hash sum is hardly relevant for the user.
Where it's relevant when the user notices that two distinct files have
the same id (because they happen to have the same contents) and
wonders what's up.
It's not a foregone conclusion that objects with the same value have
identical ids, but it's immediately apparent if the id is known to be
a hash.
--
David Abrahams
BoostPro Computing
http://boostpro.com
--
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