There still are a handful of "pack-file" remaining in the
documentation set, even after applying these three that changes
6 instances of 'pack-file' to 'packfile'.
git-index-pack.txt:'git index-pack' [-v] [-o <index-file>] <pack-file>
git-index-pack.txt: [<pack-file>]
git-index-pack.txt: instead and a copy is then written to <pack-file>. If
git-index-pack.txt: <pack-file> is not specified, the pack is written to
git-index-pack.txt: <pack-file> is not specified consider using --keep to
git-unpack-objects.txt:'git unpack-objects' [-n] [-q] [-r] [--strict] < <pack-file>
technical/pack-heuristics.txt: <linus> Anyway, the pack-file could easily be denser still, but
technical/pack-heuristics.txt: <linus> In particular, while the pack-file is then compressed,
technical/pack-heuristics.txt: <linus> Anyway: I'm not even trying to claim that the pack-files
technical/pack-protocol.txt: update-request = *shallow ( command-list | push-cert ) [pack-file]
technical/pack-protocol.txt: pack-file = "PACK" 28*(OCTET)
user-manual.txt:[[pack-files]]
A quick "git grep packfile" vs "git grep pack-file" inside
Documentation/ directory indicates that we seem to use 'packfile'
primarily in the lower-level technical documents that are not
end-user facing. Almost half of them are in the release notes
that we won't bother "fixing", so it might make sense to go the
other way around, consistently using "pack-file" that may be more
familiar to end-users.
What do others think?
On Tue, May 19, 2015 at 12:34:03PM -0700, Junio C Hamano wrote:
A quick "git grep packfile" vs "git grep pack-file" inside
Documentation/ directory indicates that we seem to use 'packfile'
primarily in the lower-level technical documents that are not
end-user facing. Almost half of them are in the release notes
that we won't bother "fixing", so it might make sense to go the
other way around, consistently using "pack-file" that may be more
familiar to end-users.
What do others think?
If I saw "pack-file" (outside of this discussion) I would think it was
wrong. That's just my opinion, of course.
Searching for "packfile" on the list yields 2145 messages. Searching for
"pack-file" yields 764. Searching for "pack file" yields 2007 (maybe
more, as my grep did not take into account line breaks).
-Peff
On Tue, May 19, 2015 at 12:34:03PM -0700, Junio C Hamano wrote:
There still are a handful of "pack-file" remaining in the
documentation set, even after applying these three that changes
6 instances of 'pack-file' to 'packfile'.
git-index-pack.txt:'git index-pack' [-v] [-o <index-file>] <pack-file>
git-index-pack.txt: [<pack-file>]
git-index-pack.txt: instead and a copy is then written to <pack-file>. If
git-index-pack.txt: <pack-file> is not specified, the pack is written to
git-index-pack.txt: <pack-file> is not specified consider using --keep to
git-unpack-objects.txt:'git unpack-objects' [-n] [-q] [-r] [--strict] < <pack-file>
technical/pack-heuristics.txt: <linus> Anyway, the pack-file could easily be denser still, but
technical/pack-heuristics.txt: <linus> In particular, while the pack-file is then compressed,
technical/pack-heuristics.txt: <linus> Anyway: I'm not even trying to claim that the pack-files
technical/pack-protocol.txt: update-request = *shallow ( command-list | push-cert ) [pack-file]
technical/pack-protocol.txt: pack-file = "PACK" 28*(OCTET)
user-manual.txt:[[pack-files]]
A quick "git grep packfile" vs "git grep pack-file" inside
Documentation/ directory indicates that we seem to use 'packfile'
primarily in the lower-level technical documents that are not
end-user facing. Almost half of them are in the release notes
that we won't bother "fixing", so it might make sense to go the
other way around, consistently using "pack-file" that may be more
familiar to end-users.
What do others think?
I was aware of the other instances of 'pack-file'. The only case
where 'pack-file' does occur after my patches, though, was as
command line parameters, where I didn't want to change it. If
that's desired I can whip up another patch.
Patrick