git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] rev-parse: clarify documentation for the --verify option

From
Michael Haggerty <mhagger@alum.mit.edu>
Date
Apr 2, 2013, 16:28 UTC
Message-ID
<515B0724.3060702@alum.mit.edu>
In-Reply-To
<7vobdxgeud.fsf@alter.siamese.dyndns.org>
On 04/02/2013 04:57 PM, Junio C Hamano wrote:
Show 48 quoted lines
> Michael Haggerty <mhagger@alum.mit.edu> writes:
> 
>> On 04/01/2013 06:56 PM, Junio C Hamano wrote:
>>> Junio C Hamano <gitster@pobox.com> writes:
>>>
>>>> Because the primary use case of this option is to implement end-user
>>>> input validation, I think it would be helpful to clarify use of the
>>>> peeler here.  Perhaps
>>>> ...
>>>
>>> A "SQUASH???" patch on top of your original is queued on 'pu',
>>> together with the earlier "^{object}" peeler patch.  Comments,
>>> improvements, etc. would be nice.
>>
>> Yes, your version is better.  I would make one change, though.  In your
>>
>> +	Make sure the single given parameter can be turned into a
>> +	raw 20-byte SHA-1 that can be used to access the object
>> +	database, and emit it to the standard output. If it can't,
>> +	error out.
>>
>> it could be made clearer that exactly one parameter should be provided.
>> Maybe
>>
>> +	Verify that exactly one parameter is provided, and that it
> 
> That is probably better (I was hoping "the single" would mean the
> same to the reader, though).  Thanks.
> 
>> +     can be turned into a raw 20-byte SHA-1 that can be used to
>> +	access the object database.  If so, emit the SHA-1 to the
>> +	standard output; otherwise, error out.
>>
>> But this makes it sound a little like the "raw 20-byte SHA-1" will be
>> output to stdout,...
> 
> I did consider that point, wrote "and outputs 40-hex" in my earlier
> draft, and then rejected it because it was even more misleading.
> The output follows the usual rules for "rev" parameters, e.g.
> 
> 	git rev-parse --short --verify HEAD
> 	git rev-parse --symbolic --verify v1.8.2^{tree}
> 
> and "--verify" does not mean 40-hex output.  That is why I left it
> vague as "emit it".
> 
> I agree that the wording incorrectly hints that you may be able to
> get 20-byte raw output.  I didn't find a satisfactory phrasing.

It's the explicit mention of "raw 20-byte" that puts the reader in mind of 20-byte binary data. I think any version that omitted that phrase would let the reader make the assumption that the SHA-1s are expressed as 40-byte hex numbers just they are everywhere else in the command-line interface.

But I'm OK with any of the variations that we have discussed.
Michael
-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
Previous: Junio C Hamano
Message 6 of 6 in “rev-parse: clarify documentation for the --verify option”
  1. rev-parse: clarify documentation for the --verify optionMichael Haggerty, Mar 30, 2013
  2. Junio C HamanoMar 31, 2013
  3. Junio C HamanoApr 1, 2013
  4. Michael HaggertyApr 2, 2013
  5. Junio C HamanoApr 2, 2013
  6. Michael HaggertyApr 2, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.