From: Junio C Hamano <gitster@pobox•com>
To: Patrick Steinhardt <ps@pks•im>
Cc: git@vger•kernel.org, Jeff King <peff@peff•net>
Subject: Re: [PATCH] doc: fix inconsistent spelling of "packfile"
Date: Thu, 21 May 2015 09:37:14 -0700 [thread overview]
Message-ID: <xmqqegm9lwed.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <1432193225-3502-1-git-send-email-ps@pks.im> (Patrick Steinhardt's message of "Thu, 21 May 2015 09:27:05 +0200")
Patrick Steinhardt <ps@pks•im> writes:
> Fix remaining instances where "pack-file" is used instead of
> "packfile".
>
> Signed-off-by: Patrick Steinhardt <ps@pks•im>
> ---
> This patch now also fixes instances where we refer to EBNF-style
> command line parameters, as discussed by Junio and Peff.
Thanks.
> diff --git a/Documentation/git-index-pack.txt b/Documentation/git-index-pack.txt
> index 7a4e055..49621da 100644
> --- a/Documentation/git-index-pack.txt
> +++ b/Documentation/git-index-pack.txt
> @@ -9,9 +9,9 @@ git-index-pack - Build pack index file for an existing packed archive
> SYNOPSIS
> --------
> [verse]
> -'git index-pack' [-v] [-o <index-file>] <pack-file>
> +'git index-pack' [-v] [-o <index-file>] <packfile>
> 'git index-pack' --stdin [--fix-thin] [--keep] [-v] [-o <index-file>]
> - [<pack-file>]
> + [<packfile>]
Hmm. The former is taking a concrete *.pack file on disk, and the
latter is optionally writing the pack stream out to a *.pack file on
disk. If we follow "'packfile' for the concept, 'pack-file' to
refer to a file with .pack ending" guideline, I'd think both should
be 'pack-file'.
Side note: because these invocations, especially the latter
form, can take any filename, you could do:
git index-pack foo.tmp && mv foo.tmp $realfilename.pack
in which case the arguments may not be files whose names end
with ".pack"; it is just a file that holds pack data stream,
so it could be argued that "packfile" is not incorrect. But
the reason why you are doing the above is to ultimately
create a *.pack file, and I'd say "pack-file" would be more
correct.
> @@ -37,11 +37,11 @@ OPTIONS
>
> --stdin::
> When this flag is provided, the pack is read from stdin
> - instead and a copy is then written to <pack-file>. If
Likewise; we are writing to a *.pack file, "written to" is not
talking about what (i.e. "packfile", the pack data stream) is
written but what accepts and holds that data stream in the end.
> - <pack-file> is not specified, the pack is written to
> + instead and a copy is then written to <packfile>. If
> + <packfile> is not specified, the pack is written to
> objects/pack/ directory of the current Git repository with
> a default name determined from the pack content. If
> - <pack-file> is not specified consider using --keep to
> + <packfile> is not specified consider using --keep to
> prevent a race condition between this process and
> 'git repack'.
All of the above talk about that same entity on the filesystem that
receives the pack data stream.
> diff --git a/Documentation/git-unpack-objects.txt b/Documentation/git-unpack-objects.txt
> index 894d20b..07d4329 100644
> --- a/Documentation/git-unpack-objects.txt
> +++ b/Documentation/git-unpack-objects.txt
> @@ -9,7 +9,7 @@ git-unpack-objects - Unpack objects from a packed archive
> SYNOPSIS
> --------
> [verse]
> -'git unpack-objects' [-n] [-q] [-r] [--strict] < <pack-file>
> +'git unpack-objects' [-n] [-q] [-r] [--strict] < <packfile>
This feeds the pack data stream to the command from its standard
input, so would be a good change.
Side note: if you have an on-disk file to feed this command
from its standard input, it is more than likely that the
file is a *.pack file, i.e. a "pack-file". But in practice,
the command is more often than not fed an output of another
command via pipe, and it only cares about it being a pack
data stream. So in that sense, both are correct but the
updated one is more correct.
> diff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt
> index 812d857..fc09c63 100644
> --- a/Documentation/technical/pack-protocol.txt
> +++ b/Documentation/technical/pack-protocol.txt
> @@ -465,7 +465,7 @@ contain all the objects that the server will need to complete the new
> references.
All changes to this file are good.
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index 68978f5..7147519 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -3164,7 +3164,7 @@ objects. (Note that linkgit:git-tag[1] can also be used to create
> "lightweight tags", which are not tag objects at all, but just simple
> references whose names begin with `refs/tags/`).
>
> -[[pack-files]]
> +[[packfiles]]
Isn't this a xref target? Can you change it without changing all
the referrers?
In any case, after doing the above two side notes, I am not sure if
readers would appreciate our careful choice of words between
"packfile" and "pack-file" when they read the documentation.
next prev parent reply other threads:[~2015-05-21 16:37 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-17 6:56 [PATCH 1/3] git-verify-pack.txt: fix inconsistent spelling of "packfile" Patrick Steinhardt
2015-05-17 6:56 ` [PATCH 2/3] git-unpack-objects.txt: " Patrick Steinhardt
2015-05-17 6:56 ` [PATCH 3/3] pack-protocol.txt: fix insconsistent " Patrick Steinhardt
2015-05-19 19:34 ` [PATCH 1/3] git-verify-pack.txt: fix inconsistent " Junio C Hamano
2015-05-19 22:24 ` Jeff King
2015-05-20 19:22 ` Junio C Hamano
2015-05-20 19:45 ` Junio C Hamano
2015-05-20 19:49 ` Jeff King
2015-05-20 22:37 ` Junio C Hamano
2015-05-21 2:04 ` Jeff King
2015-05-21 4:54 ` Junio C Hamano
2015-05-21 7:27 ` [PATCH] doc: " Patrick Steinhardt
2015-05-21 16:37 ` Junio C Hamano [this message]
2015-05-22 6:10 ` Patrick Steinhardt
2015-05-22 6:22 ` [PATCH v2] " Patrick Steinhardt
2015-05-22 16:00 ` Junio C Hamano
2015-05-20 5:13 ` [PATCH 1/3] git-verify-pack.txt: " Patrick Steinhardt
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=xmqqegm9lwed.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=peff@peff$(echo .)net \
--cc=ps@pks$(echo .)im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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