undef/git-commit-vandalism
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Merge branch 'ps/doc-packfile-vs-pack-file' into maint

Browse Source 
Doc consistency updates.

* ps/doc-packfile-vs-pack-file:
  doc: fix inconsistent spelling of "packfile"
  pack-protocol.txt: fix insconsistent spelling of "packfile"
  git-unpack-objects.txt: fix inconsistent spelling of "packfile"
  git-verify-pack.txt: fix inconsistent spelling of "packfile"
This commit is contained in:
Junio C Hamano 2015-06-05 12:00:27 -07:00
commit e41f8d98e3
3 changed files with 9 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
Documentation/git-unpack-objects.txt
View File

@ -9,7 +9,7 @@ git-unpack-objects - Unpack objects from a packed archive
SYNOPSIS SYNOPSIS
-------- --------
[verse] [verse]
'git unpack-objects' [-n] [-q] [-r] [--strict] < <pack-file> 'git unpack-objects' [-n] [-q] [-r] [--strict] < <packfile>
DESCRIPTION DESCRIPTION
@ -19,8 +19,8 @@ the objects contained within and writing them into the repository in
"loose" (one object per file) format. "loose" (one object per file) format.
Objects that already exist in the repository will *not* be unpacked Objects that already exist in the repository will *not* be unpacked
from the pack-file. Therefore, nothing will be unpacked if you use from the packfile. Therefore, nothing will be unpacked if you use
this command on a pack-file that exists within the target repository. this command on a packfile that exists within the target repository.
See linkgit:git-repack[1] for options to generate See linkgit:git-repack[1] for options to generate
new packs and replace existing ones. new packs and replace existing ones.

2
Documentation/git-verify-pack.txt
View File

@ -40,7 +40,7 @@ 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-pack-file offset-in-packfile SHA-1 type size size-in-packfile offset-in-packfile
for objects that are not deltified in the pack, and for objects that are not deltified in the pack, and

10
Documentation/technical/pack-protocol.txt
View File

@ -465,7 +465,7 @@ contain all the objects that the server will need to complete the new
references. references.
---- ----
update-request = *shallow ( command-list | push-cert ) [pack-file] update-request = *shallow ( command-list | push-cert ) [packfile]
shallow = PKT-LINE("shallow" SP obj-id LF) shallow = PKT-LINE("shallow" SP obj-id LF)
@ -491,7 +491,7 @@ references.
*PKT-LINE(gpg-signature-lines LF) *PKT-LINE(gpg-signature-lines LF)
PKT-LINE("push-cert-end" LF) PKT-LINE("push-cert-end" LF)
pack-file = "PACK" 28*(OCTET) packfile = "PACK" 28*(OCTET)
---- ----
If the receiving end does not support delete-refs, the sending end MUST If the receiving end does not support delete-refs, the sending end MUST
@ -502,11 +502,11 @@ MUST NOT send a push-cert command. When a push-cert command is
sent, command-list MUST NOT be sent; the commands recorded in the sent, command-list MUST NOT be sent; the commands recorded in the
push certificate is used instead. push certificate is used instead.
The pack-file MUST NOT be sent if the only command used is 'delete'. The packfile MUST NOT be sent if the only command used is 'delete'.
A pack-file MUST be sent if either create or update command is used, A packfile MUST be sent if either create or update command is used,
even if the server already has all the necessary objects. In this even if the server already has all the necessary objects. In this
case the client MUST send an empty pack-file. The only time this case the client MUST send an empty packfile. The only time this
is likely to happen is if the client is creating is likely to happen is if the client is creating
a new branch or a tag that points to an existing obj-id. a new branch or a tag that points to an existing obj-id.