From: "Björn Steinbrink" <B.Steinbrink@gmx.de>
To: Michael Witten <mfwitten@gmail.com>
Cc: Felipe Contreras <felipe.contreras@gmail.com>,
David Abrahams <dave@boostpro.com>, Jeff King <peff@peff.net>,
Daniel Barkalow <barkalow@iabervon.org>,
Johan Herland <johan@herland.net>,
git@vger.kernel.org, "J. Bruce Fields" <bfields@fieldses.org>
Subject: Re: Lets avoid the SHA-1 term (was [doc] User Manual Suggestion)
Date: Sat, 2 May 2009 17:37:34 +0200 [thread overview]
Message-ID: <20090502153734.GA6135@atjola.homenet> (raw)
In-Reply-To: <b4087cc50904270602q17fba432ka219180d358fae47@mail.gmail.com>
On 2009.04.27 08:02:02 -0500, Michael Witten wrote:
> 2009/4/26 Björn Steinbrink <B.Steinbrink@gmx.de>:
> >
> >> Do you agree that either 'id' or 'hash' would work fine?
> >
> > "object id" would work for me, but I'm fine with the existing "object
> > name" as well. I don't like "object hash" (or "object hash id"), because
> > it IMHO doesn't express that well that it's used to identify an object.
>
> However, the SHA-1 hash is not actually essential to git. In the git
> world, there is only content and every object is identified by its
> content. Now, to identify an object, it would be pretty cumbersome to
> have to write out the contents, so we abbreviate the contents with a
> hash.
>
> So, the hash or object name or object id or whatever you want to call
> it isn't even an essential part to git. It is a convenience.
>
> In that sense, I think that '[cryptographic] hash' is the right term,
> because the others ("object name" and "object id") seem special. A
> hash is not special. In fact, the documentation should read "For
> convenience, the git tools refer to objects using the hash value of
> their contents". You see? It's not essential.
"For convenience" means "To make it suck less for the user" to me. And
that's why you can use an abbreviated object name as long as its unique.
That a hash is used isn't essential for the basic data model, where
commits reference trees which in turn reference other trees and blobs.
To understand that model, it's not essential to know that hashes are
used. But it is essential that some kind of identifier other than the
whole content is used. Otherwise, the whole data model would make no
sense at all. If you use the whole content to identify an object, that
means that commits contain the whole trees which in turn contain the
whole other trees and the whole blobs. So you could as well just have
only commit objects, they contain everything anyway.
So that we have the object name instead of the whole content _is_
essential.
Björn
next prev parent reply other threads:[~2009-05-02 15:37 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-26 23:38 Lets avoid the SHA-1 term (was [doc] User Manual Suggestion) Felipe Contreras
2009-04-27 0:28 ` Björn Steinbrink
2009-04-27 13:02 ` Michael Witten
2009-05-02 15:37 ` Björn Steinbrink [this message]
2009-04-27 12:06 ` Michael J Gruber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090502153734.GA6135@atjola.homenet \
--to=b.steinbrink@gmx.de \
--cc=barkalow@iabervon.org \
--cc=bfields@fieldses.org \
--cc=dave@boostpro.com \
--cc=felipe.contreras@gmail.com \
--cc=git@vger.kernel.org \
--cc=johan@herland.net \
--cc=mfwitten@gmail.com \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).