From: Junio C Hamano <gitster@pobox.com>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 1/4] git-verify-* doc: update mark-up of synopsis option descriptions
Date: Thu, 01 May 2025 16:10:19 -0700 [thread overview]
Message-ID: <xmqqecx8vsf8.fsf@gitster.g> (raw)
In-Reply-To: <CAPig+cR-mbtwvUZBdhVCKsimVCETKdWHNG14hXDO77qMWMwVkg@mail.gmail.com> (Eric Sunshine's message of "Thu, 1 May 2025 18:43:46 -0400")
Eric Sunshine <sunshine@sunshineco.com> writes:
>> -'git pack-objects' command and verifies the idx file and the
>> -corresponding pack file.
>> +Read each idx file for packed Git archive given on the command line,
>> +and verify the idx file and the corresponding pack file.
>
> Okay, rewrite seems reasonable. Do we want to backtick "idx" and "pack"?
No. I would understand if it is spelled '.idx', to refer to a
concrete file suffix that people would type verbatim. In this
sentence, however, I think "idx file" and "pack file" are used as a
general noun.
>> OUTPUT FORMAT
>> -------------
>> -When specifying the -v option the format used is:
>> +When specifying the `-v` option the format used is:
>>
>> - SHA-1 type size size-in-packfile offset-in-packfile
>> + object-name type size size-in-packfile offset-in-packfile
>
> Do we not typically call this object-ID (OID) rather than object-name?
Given these entries in Documentation/glossary-content.adoc
[[def_hash]]hash::
In Git's context, synonym for <<def_object_name,object name>>.
[[def_object_identifier]]object identifier (oid)::
Synonym for <<def_object_name,object name>>.
I do not think so, and if we find somebody doing so, we should
correct them.
>> diff --git a/Documentation/git-verify-tag.adoc b/Documentation/git-verify-tag.adoc
>> @@ -7,26 +7,24 @@ git-verify-tag - Check the GPG signature of tags
>
> ...all uppercase GPG...
>
>> -Validates the gpg signature created by 'git tag'.
>> +Validates the gpg signature created by 'git tag' in the tag
>> +objects listed on the command line.
>
> ...since this is being rewritten anyhow, it probably would make sense
> to employ consistent casing of GPG.
Once the dust settles from this series, yes, but not in this series
that is about mark-up.
Thanks.
next prev parent reply other threads:[~2025-05-01 23:10 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-01 21:34 [PATCH 0/4] A handful of doc synopsis/options update Junio C Hamano
2025-05-01 21:34 ` [PATCH 1/4] git-verify-* doc: update mark-up of synopsis option descriptions Junio C Hamano
2025-05-01 22:43 ` Eric Sunshine
2025-05-01 23:10 ` Junio C Hamano [this message]
2025-05-01 21:34 ` [PATCH 2/4] git-{var,write-tree} docs: " Junio C Hamano
2025-05-01 21:34 ` [PATCH 3/4] git-daemon doc: " Junio C Hamano
2025-05-01 22:52 ` Eric Sunshine
2025-05-01 23:12 ` Junio C Hamano
2025-05-01 23:22 ` Junio C Hamano
2025-05-01 21:34 ` [WIP PATCH 4/4] git-worktree " Junio C Hamano
2025-05-03 1:15 ` [PATCH v2 0/3] A handful of doc synopsis/options update Junio C Hamano
2025-05-03 1:15 ` [PATCH v2 1/3] git-verify-* doc: update mark-up of synopsis option descriptions Junio C Hamano
2025-05-03 1:15 ` [PATCH v2 2/3] git-{var,write-tree} docs: " Junio C Hamano
2025-05-03 1:15 ` [PATCH v2 3/3] git-daemon doc: " Junio C Hamano
2025-05-07 20:58 ` Additional changes Jean-Noël Avila
2025-05-07 20:58 ` [PATCH] " Jean-Noël Avila
2025-05-08 15:14 ` Junio C Hamano
2025-05-09 12:12 ` Jean-Noël AVILA
2025-05-09 14:35 ` Junio C Hamano
2025-05-09 17:08 ` Jean-Noël AVILA
2025-05-09 18:24 ` Junio C Hamano
2025-05-10 12:33 ` [PATCH v3 0/4] " Jean-Noël Avila
2025-05-10 12:33 ` [PATCH v3 1/4] git-daemon doc: update mark-up of synopsis option descriptions Jean-Noël Avila
2025-05-10 12:33 ` [PATCH v3 2/4] git-{var,write-tree} docs: " Jean-Noël Avila
2025-05-10 12:33 ` [PATCH v3 3/4] git-verify-* doc: " Jean-Noël Avila
2025-05-10 12:33 ` [PATCH v3 4/4] git-var doc: fix usage of $ENV_VAR vs ENV_VAR Jean-Noël Avila
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=xmqqecx8vsf8.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=sunshine@sunshineco.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.