{"thread":{"id":"39349","subject":"[PATCH 2/3] git-unpack-objects.txt: fix inconsistent spelling of \"packfile\"","startedAt":"2015-05-17T06:56:52Z","lastAt":"2015-05-22T16:00:43Z","messageCount":17,"participants":["Patrick Steinhardt","Junio C Hamano","Jeff King"],"isPatch":true,"patchVersion":1,"patchTotal":3},"messages":[{"id":"261409","messageId":"1431845814-2541-1-git-send-email-ps@pks.im","threadId":"39349","inReplyTo":null,"subject":"[PATCH 1/3] git-verify-pack.txt: fix inconsistent spelling of \"packfile\"","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2015-05-17T06:56:52Z","receivedAt":"2015-05-17T06:56:52Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"Signed-off-by: Patrick Steinhardt \n---\n Documentation/git-verify-pack.txt | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/Documentation/git-verify-pack.txt b/Documentation/git-verify-pack.txt\nindex 526ba7b..61ca6d0 100644\n--- a/Documentation/git-verify-pack.txt\n+++ b/Documentation/git-verify-pack.txt\n@@ -40,7 +40,7 @@ OUTPUT FORMAT\n -------------\n When specifying the -v option the format used is:\n \n-\tSHA-1 type size size-in-pack-file offset-in-packfile\n+\tSHA-1 type size size-in-packfile offset-in-packfile\n \n for objects that are not deltified in the pack, and\n \n-- \n2.4.0\n"},{"id":"261408","messageId":"1431845814-2541-2-git-send-email-ps@pks.im","threadId":"39349","inReplyTo":"1431845814-2541-1-git-send-email-ps@pks.im","subject":"[PATCH 2/3] git-unpack-objects.txt: fix inconsistent spelling of \"packfile\"","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2015-05-17T06:56:53Z","receivedAt":"2015-05-17T06:56:53Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"Signed-off-by: Patrick Steinhardt \n---\n Documentation/git-unpack-objects.txt | 4 ++--\n 1 file changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/git-unpack-objects.txt b/Documentation/git-unpack-objects.txt\nindex 12cb108..894d20b 100644\n--- a/Documentation/git-unpack-objects.txt\n+++ b/Documentation/git-unpack-objects.txt\n@@ -19,8 +19,8 @@ the objects contained within and writing them into the repository in\n \"loose\" (one object per file) format.\n \n Objects that already exist in the repository will *not* be unpacked\n-from the pack-file. Therefore, nothing will be unpacked if you use\n-this command on a pack-file that exists within the target repository.\n+from the packfile. Therefore, nothing will be unpacked if you use\n+this command on a packfile that exists within the target repository.\n \n See linkgit:git-repack[1] for options to generate\n new packs and replace existing ones.\n-- \n2.4.0\n"},{"id":"261410","messageId":"1431845814-2541-3-git-send-email-ps@pks.im","threadId":"39349","inReplyTo":"1431845814-2541-1-git-send-email-ps@pks.im","subject":"[PATCH 3/3] pack-protocol.txt: fix insconsistent spelling of \"packfile\"","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2015-05-17T06:56:54Z","receivedAt":"2015-05-17T06:56:54Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"Signed-off-by: Patrick Steinhardt \n---\n Documentation/technical/pack-protocol.txt | 6 +++---\n 1 file changed, 3 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt\nindex 462e206..812d857 100644\n--- a/Documentation/technical/pack-protocol.txt\n+++ b/Documentation/technical/pack-protocol.txt\n@@ -502,11 +502,11 @@ MUST NOT send a push-cert command. When a push-cert command is\n sent, command-list MUST NOT be sent; the commands recorded in the\n push certificate is used instead.\n \n-The pack-file MUST NOT be sent if the only command used is 'delete'.\n+The packfile MUST NOT be sent if the only command used is 'delete'.\n \n-A pack-file MUST be sent if either create or update command is used,\n+A packfile MUST be sent if either create or update command is used,\n even if the server already has all the necessary objects. In this\n-case the client MUST send an empty pack-file. The only time this\n+case the client MUST send an empty packfile. The only time this\n is likely to happen is if the client is creating\n a new branch or a tag that points to an existing obj-id.\n \n-- \n2.4.0\n"},{"id":"261586","messageId":"xmqqwq04745w.fsf@gitster.dls.corp.google.com","threadId":"39349","inReplyTo":"1431845814-2541-1-git-send-email-ps@pks.im","subject":"Re: [PATCH 1/3] git-verify-pack.txt: fix inconsistent spelling of \"packfile\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-05-19T19:34:03Z","receivedAt":"2015-05-19T19:34:03Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"There still are a handful of \"pack-file\" remaining in the\ndocumentation set, even after applying these three that changes\n6 instances of 'pack-file' to 'packfile'.\n\ngit-index-pack.txt:'git index-pack' [-v] [-o ] \ngit-index-pack.txt: []\ngit-index-pack.txt:\tinstead and a copy is then written to . If\ngit-index-pack.txt:\t is not specified, the pack is written to\ngit-index-pack.txt:\t is not specified consider using --keep to\ngit-unpack-objects.txt:'git unpack-objects' [-n] [-q] [-r] [--strict] < \ntechnical/pack-heuristics.txt: Anyway, the pack-file could easily be denser still, but\ntechnical/pack-heuristics.txt: In particular, while the pack-file is then compressed,\ntechnical/pack-heuristics.txt: Anyway: I'm not even trying to claim that the pack-files\ntechnical/pack-protocol.txt: update-request = *shallow ( command-list | push-cert ) [pack-file]\ntechnical/pack-protocol.txt: pack-file = \"PACK\" 28*(OCTET)\nuser-manual.txt:[[pack-files]]\n\nA quick \"git grep packfile\" vs \"git grep pack-file\" inside\nDocumentation/ directory indicates that we seem to use 'packfile'\nprimarily in the lower-level technical documents that are not\nend-user facing. Almost half of them are in the release notes\nthat we won't bother \"fixing\", so it might make sense to go the\nother way around, consistently using \"pack-file\" that may be more\nfamiliar to end-users.\n\nWhat do others think?\n"},{"id":"261620","messageId":"20150519222427.GA994@peff.net","threadId":"39349","inReplyTo":"xmqqwq04745w.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 1/3] git-verify-pack.txt: fix inconsistent spelling of \"packfile\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-05-19T22:24:28Z","receivedAt":"2015-05-19T22:24:28Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, May 19, 2015 at 12:34:03PM -0700, Junio C Hamano wrote:\n\n> A quick \"git grep packfile\" vs \"git grep pack-file\" inside\n> Documentation/ directory indicates that we seem to use 'packfile'\n> primarily in the lower-level technical documents that are not\n> end-user facing. Almost half of them are in the release notes\n> that we won't bother \"fixing\", so it might make sense to go the\n> other way around, consistently using \"pack-file\" that may be more\n> familiar to end-users.\n> \n> What do others think?\n\nIf I saw \"pack-file\" (outside of this discussion) I would think it was\nwrong. That's just my opinion, of course.\n\nSearching for \"packfile\" on the list yields 2145 messages. Searching for\n\"pack-file\" yields 764. Searching for \"pack file\" yields 2007 (maybe\nmore, as my grep did not take into account line breaks).\n\n-Peff\n"},{"id":"261633","messageId":"20150520051359.GA367@pks-pc.localdomain","threadId":"39349","inReplyTo":"xmqqwq04745w.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 1/3] git-verify-pack.txt: fix inconsistent spelling of \"packfile\"","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2015-05-20T05:13:59Z","receivedAt":"2015-05-20T05:13:59Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Tue, May 19, 2015 at 12:34:03PM -0700, Junio C Hamano wrote:\n> There still are a handful of \"pack-file\" remaining in the\n> documentation set, even after applying these three that changes\n> 6 instances of 'pack-file' to 'packfile'.\n> \n> git-index-pack.txt:'git index-pack' [-v] [-o ] \n> git-index-pack.txt: []\n> git-index-pack.txt:\tinstead and a copy is then written to . If\n> git-index-pack.txt:\t is not specified, the pack is written to\n> git-index-pack.txt:\t is not specified consider using --keep to\n> git-unpack-objects.txt:'git unpack-objects' [-n] [-q] [-r] [--strict] < \n> technical/pack-heuristics.txt: Anyway, the pack-file could easily be denser still, but\n> technical/pack-heuristics.txt: In particular, while the pack-file is then compressed,\n> technical/pack-heuristics.txt: Anyway: I'm not even trying to claim that the pack-files\n> technical/pack-protocol.txt: update-request = *shallow ( command-list | push-cert ) [pack-file]\n> technical/pack-protocol.txt: pack-file = \"PACK\" 28*(OCTET)\n> user-manual.txt:[[pack-files]]\n> \n> A quick \"git grep packfile\" vs \"git grep pack-file\" inside\n> Documentation/ directory indicates that we seem to use 'packfile'\n> primarily in the lower-level technical documents that are not\n> end-user facing. Almost half of them are in the release notes\n> that we won't bother \"fixing\", so it might make sense to go the\n> other way around, consistently using \"pack-file\" that may be more\n> familiar to end-users.\n> \n> What do others think?\n\nI was aware of the other instances of 'pack-file'. The only case\nwhere 'pack-file' does occur after my patches, though, was as\ncommand line parameters, where I didn't want to change it. If\nthat's desired I can whip up another patch.\n\nPatrick\n"},{"id":"261688","messageId":"xmqqmw0znjfc.fsf@gitster.dls.corp.google.com","threadId":"39349","inReplyTo":"20150519222427.GA994@peff.net","subject":"Re: [PATCH 1/3] git-verify-pack.txt: fix inconsistent spelling of \"packfile\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-05-20T19:22:15Z","receivedAt":"2015-05-20T19:22:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Tue, May 19, 2015 at 12:34:03PM -0700, Junio C Hamano wrote:\n>\n>> A quick \"git grep packfile\" vs \"git grep pack-file\" inside\n>> Documentation/ directory indicates that we seem to use 'packfile'\n>> primarily in the lower-level technical documents that are not\n>> end-user facing. Almost half of them are in the release notes\n>> that we won't bother \"fixing\", so it might make sense to go the\n>> other way around, consistently using \"pack-file\" that may be more\n>> familiar to end-users.\n>> \n>> What do others think?\n>\n> If I saw \"pack-file\" (outside of this discussion) I would think it was\n> wrong. That's just my opinion, of course.\n\nOK, then let's go with these three patches.\n\nThanks for sanity checking.\n"},{"id":"261701","messageId":"xmqqd21vnid6.fsf@gitster.dls.corp.google.com","threadId":"39349","inReplyTo":"xmqqmw0znjfc.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 1/3] git-verify-pack.txt: fix inconsistent spelling of \"packfile\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-05-20T19:45:09Z","receivedAt":"2015-05-20T19:45:09Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Jeff King writes:\n>\n>> On Tue, May 19, 2015 at 12:34:03PM -0700, Junio C Hamano wrote:\n>>\n>>> A quick \"git grep packfile\" vs \"git grep pack-file\" inside\n>>> Documentation/ directory indicates that we seem to use 'packfile'\n>>> primarily in the lower-level technical documents that are not\n>>> end-user facing. Almost half of them are in the release notes\n>>> that we won't bother \"fixing\", so it might make sense to go the\n>>> other way around, consistently using \"pack-file\" that may be more\n>>> familiar to end-users.\n>>> \n>>> What do others think?\n>>\n>> If I saw \"pack-file\" (outside of this discussion) I would think it was\n>> wrong. That's just my opinion, of course.\n>\n> OK, then let's go with these three patches.\n>\n> Thanks for sanity checking.\n\nBy the way, the way we spell these two entities in the glossary is\n\n \"pack\" - that which holds collection of objects tightly packed\n \"pack index\" - that which allows a random access into a \"pack\"\n\nWe may want to do two things:\n\n (1) add \"packfile\" as a synonym to the former; I think the origin\n of \"pack file\" is that it would clarify which one we refer to\n it as an on-disk entity when contrasting a \"pack\" and its\n associated \"pack index\", and I even suspect that originally we\n spelled it as two words, later contracted with dash (as seen in\n the pack-heuristics irc lecture given by Linus).\n\n (2) describe \"pack bitmap\", which came long after the original\n glossary entries are made.\n\nAnd if we are going that route, we should fix the SYNOPSIS sections\nand usage[] strings of \"index-pack\" and \"unpack-objects\" where we\nsay these commands read from \"\" (we now read from\n\"\").\n\nI am undecided if we want to touch Documentation/technical/. The\nirc lecture in pack-heuristics.txt is a historical recording and it\nmay be OK to keep it as it is. pack-protocol.txt consistently uses\n\"packfile\" in prose and uses \"pack-file\" in EBNF. From a quick\nre-reading of the document, I think it is OK to use \"packfile\"\nthroughout there.\n\nOne related thing is that there are few mentions of \"idx file\" to\nrefer to \"pack index\" (e.g. show-index and verify-pack documentation\npages); I think this was an attempt to disambiguate \"pack index\"\nfrom \"the Index\", but as long as we spell it \"pack index\", I think\nit should be OK, so while we are at it we may want to fix them. We\ncan leave \"pack .idx file\" as-is, but rewriting it to \"pack index\nfile\" or just \"pack index\" may be OK as long as it is clear from the\ncontext.\n\n\"git show-index\" has this in SYNOPSIS:\n\n\t'git show-index' < idx-file\n\nIt probably should become\n\n\t'git show-index' < \n"},{"id":"261703","messageId":"20150520194906.GA8421@peff.net","threadId":"39349","inReplyTo":"xmqqd21vnid6.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 1/3] git-verify-pack.txt: fix inconsistent spelling of \"packfile\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-05-20T19:49:07Z","receivedAt":"2015-05-20T19:49:07Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, May 20, 2015 at 12:45:09PM -0700, Junio C Hamano wrote:\n\n> One related thing is that there are few mentions of \"idx file\" to\n> refer to \"pack index\" (e.g. show-index and verify-pack documentation\n> pages); I think this was an attempt to disambiguate \"pack index\"\n> from \"the Index\", but as long as we spell it \"pack index\", I think\n> it should be OK, so while we are at it we may want to fix them. We\n> can leave \"pack .idx file\" as-is, but rewriting it to \"pack index\n> file\" or just \"pack index\" may be OK as long as it is clear from the\n> context.\n> \n> \"git show-index\" has this in SYNOPSIS:\n> \n> \t'git show-index' < idx-file\n> \n> It probably should become\n> \n> \t'git show-index' < \n\nThat makes \"pack-file\" make more sense to me. It is not \"the abstract\nconcept of a packfile\", but \"the file with the .pack extension\" (just as\n\"idx-file\" is \"the file with the .idx extension\"). They are the same\nthing if you think about it, of course, but you might choose one over\nthe other depending on the context.\n\n-Peff\n"},{"id":"261726","messageId":"xmqqzj4ylvto.fsf@gitster.dls.corp.google.com","threadId":"39349","inReplyTo":"20150520194906.GA8421@peff.net","subject":"Re: [PATCH 1/3] git-verify-pack.txt: fix inconsistent spelling of \"packfile\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-05-20T22:37:23Z","receivedAt":"2015-05-20T22:37:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Wed, May 20, 2015 at 12:45:09PM -0700, Junio C Hamano wrote:\n>\n>> One related thing is that there are few mentions of \"idx file\" to\n>> refer to \"pack index\" (e.g. show-index and verify-pack documentation\n>> pages); I think this was an attempt to disambiguate \"pack index\"\n>> from \"the Index\", but as long as we spell it \"pack index\", I think\n>> it should be OK, so while we are at it we may want to fix them. We\n>> can leave \"pack .idx file\" as-is, but rewriting it to \"pack index\n>> file\" or just \"pack index\" may be OK as long as it is clear from the\n>> context.\n>> \n>> \"git show-index\" has this in SYNOPSIS:\n>> \n>> \t'git show-index' < idx-file\n>> \n>> It probably should become\n>> \n>> \t'git show-index' < \n>\n> That makes \"pack-file\" make more sense to me. It is not \"the abstract\n> concept of a packfile\", but \"the file with the .pack extension\" (just as\n> \"idx-file\" is \"the file with the .idx extension\"). They are the same\n> thing if you think about it, of course, but you might choose one over\n> the other depending on the context.\n\nHmm, that is also true.\n\nIn any case, even though I merged these three to 'next', I think we\nneed to either revert 3/3 or do s/pack-file/packfile/ throughout the\npack-protocol documentation. The original has something like this:\n\n The pack-file MUST NOT be sent if the only command used is 'delete'.\n\n A pack-file MUST be sent if either create or update command is used,\n even if the server already has all the necessary objects. In this\n case the client MUST send an empty pack-file. The only time this\n is likely to happen is if the client is creating\n a new branch or a tag that points to an existing obj-id.\n\nand these are explicitly referring to what EBNF defines as \"pack-file\".\nChanging them to \"packfile\" is simply wrong.\n"},{"id":"261729","messageId":"20150521020402.GA11619@peff.net","threadId":"39349","inReplyTo":"xmqqzj4ylvto.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 1/3] git-verify-pack.txt: fix inconsistent spelling of \"packfile\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-05-21T02:04:03Z","receivedAt":"2015-05-21T02:04:03Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, May 20, 2015 at 03:37:23PM -0700, Junio C Hamano wrote:\n\n> In any case, even though I merged these three to 'next', I think we\n> need to either revert 3/3 or do s/pack-file/packfile/ throughout the\n> pack-protocol documentation. The original has something like this:\n> \n> The pack-file MUST NOT be sent if the only command used is 'delete'.\n> \n> A pack-file MUST be sent if either create or update command is used,\n> even if the server already has all the necessary objects. In this\n> case the client MUST send an empty pack-file. The only time this\n> is likely to happen is if the client is creating\n> a new branch or a tag that points to an existing obj-id.\n> \n> and these are explicitly referring to what EBNF defines as \"pack-file\".\n> Changing them to \"packfile\" is simply wrong.\n\nYeah, I agree they should agree with the EBNF. And my inclination is for\n\"packfile\", as it is refering to the concept of the on-the-wire packfile\ndata (there is no \"file ending in .pack\" in this context).\n\nWhich I guess argues for a further patch.\n\n-Peff\n"},{"id":"261750","messageId":"xmqqr3qaledb.fsf@gitster.dls.corp.google.com","threadId":"39349","inReplyTo":"20150521020402.GA11619@peff.net","subject":"Re: [PATCH 1/3] git-verify-pack.txt: fix inconsistent spelling of \"packfile\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-05-21T04:54:24Z","receivedAt":"2015-05-21T04:54:24Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Yeah, I agree they should agree with the EBNF. And my inclination is for\n> \"packfile\", as it is refering to the concept of the on-the-wire packfile\n> data (there is no \"file ending in .pack\" in this context).\n>\n> Which I guess argues for a further patch.\n\nI'm fine with that, then.\n\nIf I had a time machine, I would have used \"pack data\" (or \"pack\nstream\") vs \"pack file\" (or \".pack file\") to differentiatee (as the\npack-protocol is not about transferring any \"file\", but just carries\n\"pack data\"), but that is a rename with more cost than warranted for\na minuscule gain at this point.\n"},{"id":"261758","messageId":"1432193225-3502-1-git-send-email-ps@pks.im","threadId":"39349","inReplyTo":"xmqqr3qaledb.fsf@gitster.dls.corp.google.com","subject":"[PATCH] doc: fix inconsistent spelling of \"packfile\"","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2015-05-21T07:27:05Z","receivedAt":"2015-05-21T07:27:05Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"Fix remaining instances where \"pack-file\" is used instead of\n\"packfile\".\n\nSigned-off-by: Patrick Steinhardt \n---\nThis patch now also fixes instances where we refer to EBNF-style\ncommand line parameters, as discussed by Junio and Peff.\n\n Documentation/git-index-pack.txt | 10 +++++-----\n Documentation/git-unpack-objects.txt | 2 +-\n Documentation/technical/pack-protocol.txt | 4 ++--\n Documentation/user-manual.txt | 2 +-\n 4 files changed, 9 insertions(+), 9 deletions(-)\n\ndiff --git a/Documentation/git-index-pack.txt b/Documentation/git-index-pack.txt\nindex 7a4e055..49621da 100644\n--- a/Documentation/git-index-pack.txt\n+++ b/Documentation/git-index-pack.txt\n@@ -9,9 +9,9 @@ git-index-pack - Build pack index file for an existing packed archive\n SYNOPSIS\n --------\n [verse]\n-'git index-pack' [-v] [-o ] \n+'git index-pack' [-v] [-o ] \n 'git index-pack' --stdin [--fix-thin] [--keep] [-v] [-o ]\n- []\n+\t\t []\n \n \n DESCRIPTION\n@@ -37,11 +37,11 @@ OPTIONS\n \n --stdin::\n \tWhen this flag is provided, the pack is read from stdin\n-\tinstead and a copy is then written to . If\n-\t is not specified, the pack is written to\n+\tinstead and a copy is then written to . If\n+\t is not specified, the pack is written to\n \tobjects/pack/ directory of the current Git repository with\n \ta default name determined from the pack content. If\n-\t is not specified consider using --keep to\n+\t is not specified consider using --keep to\n \tprevent a race condition between this process and\n \t'git repack'.\n \ndiff --git a/Documentation/git-unpack-objects.txt b/Documentation/git-unpack-objects.txt\nindex 894d20b..07d4329 100644\n--- a/Documentation/git-unpack-objects.txt\n+++ b/Documentation/git-unpack-objects.txt\n@@ -9,7 +9,7 @@ git-unpack-objects - Unpack objects from a packed archive\n SYNOPSIS\n --------\n [verse]\n-'git unpack-objects' [-n] [-q] [-r] [--strict] < \n+'git unpack-objects' [-n] [-q] [-r] [--strict] < \n \n \n DESCRIPTION\ndiff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt\nindex 812d857..fc09c63 100644\n--- a/Documentation/technical/pack-protocol.txt\n+++ b/Documentation/technical/pack-protocol.txt\n@@ -465,7 +465,7 @@ contain all the objects that the server will need to complete the new\n references.\n \n ----\n- update-request = *shallow ( command-list | push-cert ) [pack-file]\n+ update-request = *shallow ( command-list | push-cert ) [packfile]\n \n shallow = PKT-LINE(\"shallow\" SP obj-id LF)\n \n@@ -491,7 +491,7 @@ references.\n \t\t *PKT-LINE(gpg-signature-lines LF)\n \t\t PKT-LINE(\"push-cert-end\" LF)\n \n- pack-file = \"PACK\" 28*(OCTET)\n+ packfile = \"PACK\" 28*(OCTET)\n ----\n \n If the receiving end does not support delete-refs, the sending end MUST\ndiff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt\nindex 68978f5..7147519 100644\n--- a/Documentation/user-manual.txt\n+++ b/Documentation/user-manual.txt\n@@ -3164,7 +3164,7 @@ objects. (Note that linkgit:git-tag[1] can also be used to create\n \"lightweight tags\", which are not tag objects at all, but just simple\n references whose names begin with `refs/tags/`).\n \n-[[pack-files]]\n+[[packfiles]]\n How Git stores objects efficiently: pack files\n ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n \n-- \n2.4.1\n"},{"id":"261797","messageId":"xmqqegm9lwed.fsf@gitster.dls.corp.google.com","threadId":"39349","inReplyTo":"1432193225-3502-1-git-send-email-ps@pks.im","subject":"Re: [PATCH] doc: fix inconsistent spelling of \"packfile\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-05-21T16:37:14Z","receivedAt":"2015-05-21T16:37:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Patrick Steinhardt writes:\n\n> Fix remaining instances where \"pack-file\" is used instead of\n> \"packfile\".\n>\n> Signed-off-by: Patrick Steinhardt \n> ---\n> This patch now also fixes instances where we refer to EBNF-style\n> command line parameters, as discussed by Junio and Peff.\n\nThanks.\n\n> diff --git a/Documentation/git-index-pack.txt b/Documentation/git-index-pack.txt\n> index 7a4e055..49621da 100644\n> --- a/Documentation/git-index-pack.txt\n> +++ b/Documentation/git-index-pack.txt\n> @@ -9,9 +9,9 @@ git-index-pack - Build pack index file for an existing packed archive\n> SYNOPSIS\n> --------\n> [verse]\n> -'git index-pack' [-v] [-o ] \n> +'git index-pack' [-v] [-o ] \n> 'git index-pack' --stdin [--fix-thin] [--keep] [-v] [-o ]\n> - []\n> +\t\t []\n\nHmm. The former is taking a concrete *.pack file on disk, and the\nlatter is optionally writing the pack stream out to a *.pack file on\ndisk. If we follow \"'packfile' for the concept, 'pack-file' to\nrefer to a file with .pack ending\" guideline, I'd think both should\nbe 'pack-file'.\n\n\tSide note: because these invocations, especially the latter\n\tform, can take any filename, you could do:\n\n \tgit index-pack foo.tmp && mv foo.tmp $realfilename.pack\n\n\tin which case the arguments may not be files whose names end\n\twith \".pack\"; it is just a file that holds pack data stream,\n\tso it could be argued that \"packfile\" is not incorrect. But\n\tthe reason why you are doing the above is to ultimately\n\tcreate a *.pack file, and I'd say \"pack-file\" would be more\n\tcorrect.\n\n> @@ -37,11 +37,11 @@ OPTIONS\n> \n> --stdin::\n> \tWhen this flag is provided, the pack is read from stdin\n> -\tinstead and a copy is then written to . If\n\nLikewise; we are writing to a *.pack file, \"written to\" is not\ntalking about what (i.e. \"packfile\", the pack data stream) is\nwritten but what accepts and holds that data stream in the end.\n\n> -\t is not specified, the pack is written to\n> +\tinstead and a copy is then written to . If\n> +\t is not specified, the pack is written to\n> \tobjects/pack/ directory of the current Git repository with\n> \ta default name determined from the pack content. If\n> -\t is not specified consider using --keep to\n> +\t is not specified consider using --keep to\n> \tprevent a race condition between this process and\n> \t'git repack'.\n\nAll of the above talk about that same entity on the filesystem that\nreceives the pack data stream.\n\n> diff --git a/Documentation/git-unpack-objects.txt b/Documentation/git-unpack-objects.txt\n> index 894d20b..07d4329 100644\n> --- a/Documentation/git-unpack-objects.txt\n> +++ b/Documentation/git-unpack-objects.txt\n> @@ -9,7 +9,7 @@ git-unpack-objects - Unpack objects from a packed archive\n> SYNOPSIS\n> --------\n> [verse]\n> -'git unpack-objects' [-n] [-q] [-r] [--strict] < \n> +'git unpack-objects' [-n] [-q] [-r] [--strict] < \n\nThis feeds the pack data stream to the command from its standard\ninput, so would be a good change.\n\n\tSide note: if you have an on-disk file to feed this command\n\tfrom its standard input, it is more than likely that the\n\tfile is a *.pack file, i.e. a \"pack-file\". But in practice,\n\tthe command is more often than not fed an output of another\n\tcommand via pipe, and it only cares about it being a pack\n\tdata stream. So in that sense, both are correct but the\n\tupdated one is more correct.\n\n> diff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt\n> index 812d857..fc09c63 100644\n> --- a/Documentation/technical/pack-protocol.txt\n> +++ b/Documentation/technical/pack-protocol.txt\n> @@ -465,7 +465,7 @@ contain all the objects that the server will need to complete the new\n> references.\n\nAll changes to this file are good.\n\n> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt\n> index 68978f5..7147519 100644\n> --- a/Documentation/user-manual.txt\n> +++ b/Documentation/user-manual.txt\n> @@ -3164,7 +3164,7 @@ objects. (Note that linkgit:git-tag[1] can also be used to create\n> \"lightweight tags\", which are not tag objects at all, but just simple\n> references whose names begin with `refs/tags/`).\n> \n> -[[pack-files]]\n> +[[packfiles]]\n\nIsn't this a xref target? Can you change it without changing all\nthe referrers?\n\n\nIn any case, after doing the above two side notes, I am not sure if\nreaders would appreciate our careful choice of words between\n\"packfile\" and \"pack-file\" when they read the documentation.\n"},{"id":"261881","messageId":"20150522061015.GA386@pks-pc.localdomain","threadId":"39349","inReplyTo":"xmqqegm9lwed.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] doc: fix inconsistent spelling of \"packfile\"","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2015-05-22T06:10:15Z","receivedAt":"2015-05-22T06:10:15Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Thu, May 21, 2015 at 09:37:14AM -0700, Junio C Hamano wrote:\n> Patrick Steinhardt writes:\n> \n> > Fix remaining instances where \"pack-file\" is used instead of\n> > \"packfile\".\n> >\n> > Signed-off-by: Patrick Steinhardt \n> > ---\n> > This patch now also fixes instances where we refer to EBNF-style\n> > command line parameters, as discussed by Junio and Peff.\n> \n> Thanks.\n> \n> > diff --git a/Documentation/git-index-pack.txt b/Documentation/git-index-pack.txt\n> > index 7a4e055..49621da 100644\n> > --- a/Documentation/git-index-pack.txt\n> > +++ b/Documentation/git-index-pack.txt\n> > @@ -9,9 +9,9 @@ git-index-pack - Build pack index file for an existing packed archive\n> > SYNOPSIS\n> > --------\n> > [verse]\n> > -'git index-pack' [-v] [-o ] \n> > +'git index-pack' [-v] [-o ] \n> > 'git index-pack' --stdin [--fix-thin] [--keep] [-v] [-o ]\n> > - []\n> > +\t\t []\n> \n> Hmm. The former is taking a concrete *.pack file on disk, and the\n> latter is optionally writing the pack stream out to a *.pack file on\n> disk. If we follow \"'packfile' for the concept, 'pack-file' to\n> refer to a file with .pack ending\" guideline, I'd think both should\n> be 'pack-file'.\n> \n> \tSide note: because these invocations, especially the latter\n> \tform, can take any filename, you could do:\n> \n> \tgit index-pack foo.tmp && mv foo.tmp $realfilename.pack\n> \n> \tin which case the arguments may not be files whose names end\n> \twith \".pack\"; it is just a file that holds pack data stream,\n> \tso it could be argued that \"packfile\" is not incorrect. But\n> \tthe reason why you are doing the above is to ultimately\n> \tcreate a *.pack file, and I'd say \"pack-file\" would be more\n> \tcorrect.\n> \n> > @@ -37,11 +37,11 @@ OPTIONS\n> > \n> > --stdin::\n> > \tWhen this flag is provided, the pack is read from stdin\n> > -\tinstead and a copy is then written to . If\n> \n> Likewise; we are writing to a *.pack file, \"written to\" is not\n> talking about what (i.e. \"packfile\", the pack data stream) is\n> written but what accepts and holds that data stream in the end.\n> \n> > -\t is not specified, the pack is written to\n> > +\tinstead and a copy is then written to . If\n> > +\t is not specified, the pack is written to\n> > \tobjects/pack/ directory of the current Git repository with\n> > \ta default name determined from the pack content. If\n> > -\t is not specified consider using --keep to\n> > +\t is not specified consider using --keep to\n> > \tprevent a race condition between this process and\n> > \t'git repack'.\n> \n> All of the above talk about that same entity on the filesystem that\n> receives the pack data stream.\n> \n> > diff --git a/Documentation/git-unpack-objects.txt b/Documentation/git-unpack-objects.txt\n> > index 894d20b..07d4329 100644\n> > --- a/Documentation/git-unpack-objects.txt\n> > +++ b/Documentation/git-unpack-objects.txt\n> > @@ -9,7 +9,7 @@ git-unpack-objects - Unpack objects from a packed archive\n> > SYNOPSIS\n> > --------\n> > [verse]\n> > -'git unpack-objects' [-n] [-q] [-r] [--strict] < \n> > +'git unpack-objects' [-n] [-q] [-r] [--strict] < \n> \n> This feeds the pack data stream to the command from its standard\n> input, so would be a good change.\n> \n> \tSide note: if you have an on-disk file to feed this command\n> \tfrom its standard input, it is more than likely that the\n> \tfile is a *.pack file, i.e. a \"pack-file\". But in practice,\n> \tthe command is more often than not fed an output of another\n> \tcommand via pipe, and it only cares about it being a pack\n> \tdata stream. So in that sense, both are correct but the\n> \tupdated one is more correct.\n> \n> > diff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt\n> > index 812d857..fc09c63 100644\n> > --- a/Documentation/technical/pack-protocol.txt\n> > +++ b/Documentation/technical/pack-protocol.txt\n> > @@ -465,7 +465,7 @@ contain all the objects that the server will need to complete the new\n> > references.\n> \n> All changes to this file are good.\n> \n> > diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt\n> > index 68978f5..7147519 100644\n> > --- a/Documentation/user-manual.txt\n> > +++ b/Documentation/user-manual.txt\n> > @@ -3164,7 +3164,7 @@ objects. (Note that linkgit:git-tag[1] can also be used to create\n> > \"lightweight tags\", which are not tag objects at all, but just simple\n> > references whose names begin with `refs/tags/`).\n> > \n> > -[[pack-files]]\n> > +[[packfiles]]\n> \n> Isn't this a xref target? Can you change it without changing all\n> the referrers?\n\nI did not find any referrers pointing to this, so I just changed\nit. I do not know if there are any referrers from outside, so I\nguess I'll just revert that back to [[pack-files]] as it is not\nseen by users anyway.\n\n> In any case, after doing the above two side notes, I am not sure if\n> readers would appreciate our careful choice of words between\n> \"packfile\" and \"pack-file\" when they read the documentation.\n\nExactly my thought by now. While it sure is nice to have the\ntechnically most-correct terms in use I guess the user will not\nrealize that we are talking about different things when referring\nto \"pack-files\" as opposed to \"packfiles\". I doubt it will hurt\nthough as the user will certainly just skim over it without\nrealizing that we sometimes use one or the other, as long as they\nare not used together in a single paragraph.\n\nPatrick\n"},{"id":"261882","messageId":"1432275724-3187-1-git-send-email-ps@pks.im","threadId":"39349","inReplyTo":"1432193225-3502-1-git-send-email-ps@pks.im","subject":"[PATCH v2] doc: fix inconsistent spelling of \"packfile\"","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2015-05-22T06:22:04Z","receivedAt":"2015-05-22T06:22:04Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"Fix remaining instances where \"pack-file\" is used instead of\n\"packfile\". Some places remain where we still use \"pack-file\",\nThis is the case when we explicitly refer to a file with a\n\".pack\" extension as opposed to a data source providing a pack\ndata stream.\n\nSigned-off-by: Patrick Steinhardt \n---\n Documentation/git-unpack-objects.txt | 2 +-\n Documentation/technical/pack-protocol.txt | 4 ++--\n 2 files changed, 3 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/git-unpack-objects.txt b/Documentation/git-unpack-objects.txt\nindex 894d20b..07d4329 100644\n--- a/Documentation/git-unpack-objects.txt\n+++ b/Documentation/git-unpack-objects.txt\n@@ -9,7 +9,7 @@ git-unpack-objects - Unpack objects from a packed archive\n SYNOPSIS\n --------\n [verse]\n-'git unpack-objects' [-n] [-q] [-r] [--strict] < \n+'git unpack-objects' [-n] [-q] [-r] [--strict] < \n \n \n DESCRIPTION\ndiff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt\nindex 812d857..fc09c63 100644\n--- a/Documentation/technical/pack-protocol.txt\n+++ b/Documentation/technical/pack-protocol.txt\n@@ -465,7 +465,7 @@ contain all the objects that the server will need to complete the new\n references.\n \n ----\n- update-request = *shallow ( command-list | push-cert ) [pack-file]\n+ update-request = *shallow ( command-list | push-cert ) [packfile]\n \n shallow = PKT-LINE(\"shallow\" SP obj-id LF)\n \n@@ -491,7 +491,7 @@ references.\n \t\t *PKT-LINE(gpg-signature-lines LF)\n \t\t PKT-LINE(\"push-cert-end\" LF)\n \n- pack-file = \"PACK\" 28*(OCTET)\n+ packfile = \"PACK\" 28*(OCTET)\n ----\n \n If the receiving end does not support delete-refs, the sending end MUST\n-- \n2.4.1\n"},{"id":"261921","messageId":"xmqq8ucgfvpw.fsf@gitster.dls.corp.google.com","threadId":"39349","inReplyTo":"1432275724-3187-1-git-send-email-ps@pks.im","subject":"Re: [PATCH v2] doc: fix inconsistent spelling of \"packfile\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-05-22T16:00:43Z","receivedAt":"2015-05-22T16:00:43Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Patrick Steinhardt writes:\n\n> Fix remaining instances where \"pack-file\" is used instead of\n> \"packfile\". Some places remain where we still use \"pack-file\",\n> This is the case when we explicitly refer to a file with a\n> \".pack\" extension as opposed to a data source providing a pack\n> data stream.\n\n\nThanks.\n"}]}