From: "Björn Steinbrink" <B.Steinbrink@gmx.de>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: David Abrahams <dave@boostpro.com>,
Michael Witten <mfwitten@gmail.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: Mon, 27 Apr 2009 02:28:38 +0200 [thread overview]
Message-ID: <20090427002838.GF12338@atjola.homenet> (raw)
In-Reply-To: <94a0d4530904261638o6cbda368p4f3aa641505a6768@mail.gmail.com>
On 2009.04.27 02:38:40 +0300, Felipe Contreras wrote:
> 2009/4/27 Björn Steinbrink <B.Steinbrink@gmx.de>:
> > On 2009.04.24 20:48:57 -0400, David Abrahams wrote:
> >>
> >> On Apr 24, 2009, at 8:01 PM, Michael Witten wrote:
> >>
> >>>> What's wrong with just calling the object name "object name"?
> >>>
> >>> What's wrong with calling the object address "object address"?
> >>
> >> Neither captures the connection to the object's contents. I think
> >> "value ID" would be closer, but it's probably too horrible.
> >
> > I think I asked this in another mail, but I'm quite tired, so just to
> > make sure: What do you mean by "value"? I might be weird (I'm not a
> > native speaker, so I probably make funny and wrong connotations from
> > time to time), but while I can accept "content" to include the type and
> > size of the object, the term "value" makes me want to exclude those
> > pieces of meta data. So "value" somehow feels wrong to me, as the hash
> > covers those two fields.
>
> Just to summarize.
>
> Do you agree that SHA-1 is not the proper term to choose?
Yes, IMHO that's too strongly tied to the implementation. But a quick
grep run tells me that the "object name" area is probably not where you
need to get rid of that. The "object name" term is already used a lot.
If you want to ban SHA-1 then the rev-parse man page, describing the
"extended SHA1 syntax" would probably be a better place to start (unless
you want to "fix" everything at once).
> 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.
> Personally I think there's an advantage of choosing 'hash'; if we pick
> 'id' then the user might think that he can change the contents of the
> object while keeping the same id, if we pick 'hash' then it's obvious
> the 'id' is tied to the content and why.
Heh, if you use "hash", there's no "id" tied to the content, there's
just the hash. SCNR ;-) See my other mails why I think that "hash" isn't
that advantageous.
Björn
next prev parent reply other threads:[~2009-04-27 0:32 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 [this message]
2009-04-27 13:02 ` Michael Witten
2009-05-02 15:37 ` Björn Steinbrink
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=20090427002838.GF12338@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