{"thread":{"id":"55631","subject":"[PATCH] Optimize the description of the configuration in packfile-uris doc","startedAt":"2021-05-06T07:34:22Z","lastAt":"2021-05-25T00:34:28Z","messageCount":12,"participants":["Teng Long","Jonathan Tan","Junio C Hamano","Long Teng"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"423750","messageId":"20210506073354.27833-1-dyroneteng@gmail.com","threadId":"55631","inReplyTo":null,"subject":"[PATCH] Optimize the description of the configuration in packfile-uris doc","fromName":"Teng Long","fromEmail":"dyroneteng@gmail.com","sentAt":"2021-05-06T07:33:54Z","receivedAt":"2021-05-06T07:34:22Z","isPatch":true,"sender":{"key":"dyroneteng@gmail.com","avatar":"https://avatars.githubusercontent.com/u/7803958?v=4"},"body":"There is a description problem in the document about packfile-uris. This\npatch describes the configuration format of `uploadpack.blobPackfileUri`\nmore accurately.\n\nSigned-off-by: Teng Long <dyroneteng@gmail.com>\n---\n Documentation/technical/packfile-uri.txt | 15 ++++++++-------\n 1 file changed, 8 insertions(+), 7 deletions(-)\n\ndiff --git a/Documentation/technical/packfile-uri.txt b/Documentation/technical/packfile-uri.txt\nindex f7eabc6c76..1eb525fe76 100644\n--- a/Documentation/technical/packfile-uri.txt\n+++ b/Documentation/technical/packfile-uri.txt\n@@ -35,13 +35,14 @@ include some sort of non-trivial implementation in the Minimum Viable Product,\n at least so that we can test the client.\n \n This is the implementation: a feature, marked experimental, that allows the\n-server to be configured by one or more `uploadpack.blobPackfileUri=<sha1>\n-<uri>` entries. Whenever the list of objects to be sent is assembled, all such\n-blobs are excluded, replaced with URIs. As noted in \"Future work\" below, the\n-server can evolve in the future to support excluding other objects (or other\n-implementations of servers could be made that support excluding other objects)\n-without needing a protocol change, so clients should not expect that packfiles\n-downloaded in this way only contain single blobs.\n+server to be configured by one or more `uploadpack.blobPackfileUri=\n+<object-hash> <pack-hash> <uri>` entries. Whenever the list of objects to be\n+sent is assembled, all such blobs are excluded, replaced with URIs. As noted\n+in \"Future work\" below, the server can evolve in the future to support\n+excluding other objects (or other implementations of servers could be made\n+that support excluding other objects) without needing a protocol change, so\n+clients should not expect that packfiles downloaded in this way only contain\n+single blobs.\n \n Client design\n -------------\n-- \n2.31.1\n\n"},{"id":"423799","messageId":"20210506164728.336409-1-jonathantanmy@google.com","threadId":"55631","inReplyTo":"20210506073354.27833-1-dyroneteng@gmail.com","subject":"Re: [PATCH] Optimize the description of the configuration in packfile-uris doc","fromName":"Jonathan Tan","fromEmail":"jonathantanmy@google.com","sentAt":"2021-05-06T16:47:28Z","receivedAt":"2021-05-06T16:47:34Z","isPatch":true,"sender":{"key":"jonathantanmy@fastmail.com","avatar":null},"body":"> There is a description problem in the document about packfile-uris. This\n> patch describes the configuration format of `uploadpack.blobPackfileUri`\n> more accurately.\n\nThanks for noticing this. The diff itself is correct, of course.\n\nAs for the commit message, limit the title to 50 characters or fewer if\npossible. Maybe something like \"packfile-uri.txt: fix blobPackfileUri\ndescription\" or something like that.\n\nAlso in the commit message, maybe mention that the correct format can be\nseen in t5702.\n"},{"id":"423824","messageId":"xmqq4kffy224.fsf@gitster.g","threadId":"55631","inReplyTo":"20210506164728.336409-1-jonathantanmy@google.com","subject":"Re: [PATCH] Optimize the description of the configuration in packfile-uris doc","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-05-06T21:39:31Z","receivedAt":"2021-05-06T21:39:36Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Tan <jonathantanmy@google.com> writes:\n\n>> There is a description problem in the document about packfile-uris. This\n>> patch describes the configuration format of `uploadpack.blobPackfileUri`\n>> more accurately.\n>\n> Thanks for noticing this. The diff itself is correct, of course.\n>\n> As for the commit message, limit the title to 50 characters or fewer if\n> possible. Maybe something like \"packfile-uri.txt: fix blobPackfileUri\n> description\" or something like that.\n>\n> Also in the commit message, maybe mention that the correct format can be\n> seen in t5702.\n\nThanks for giving a review with clear suggestion for improvements,\nJonathan.  And thanks for contributing, Teng.\n\nWill look forward to seeing an updated patch.\n"},{"id":"424112","messageId":"20210511064554.59924-1-dyroneteng@gmail.com","threadId":"55631","inReplyTo":"xmqq4kffy224.fsf@gitster.g","subject":"[PATCH v2] packfile-uri.txt: fix blobPackfileUri description","fromName":"Teng Long","fromEmail":"dyroneteng@gmail.com","sentAt":"2021-05-11T06:45:54Z","receivedAt":"2021-05-11T06:46:23Z","isPatch":true,"sender":{"key":"dyroneteng@gmail.com","avatar":"https://avatars.githubusercontent.com/u/7803958?v=4"},"body":"Fix the 'uploadpack.blobPackfileUri' description in packfile-uri.txt\nand the correct format also can be seen in t5702.\n\nJonathan Tan <jonathantanmy@google.com> writes:\n\n>As for the commit message, limit the title to 50 characters or fewer if\n>possible. Maybe something like \"packfile-uri.txt: fix blobPackfileUri\n>description\" or something like that.\n\nThanks for mention this, \"packfile-uri.txt: fix blobPackfileUri\ndescription\" is good and meets the \"50 characters\" requirement. So the\ntitle is modified. \n\n>Also in the commit message, maybe mention that the correct format can be\n>seen in t5702.\n\nBecause I am implementing another patch[1] about supporting the commit\nobject in packfile-uri, I noticed the `configure_exclusion` function in\nt5702, which is now mentioned in the commit message.\n\n[1]https://public-inbox.org/git/20210507021140.31372-1-dyroneteng@gmail.com\n\nSigned-off-by: Teng Long <dyroneteng@gmail.com>\n---\n Documentation/technical/packfile-uri.txt | 15 ++++++++-------\n 1 file changed, 8 insertions(+), 7 deletions(-)\n\ndiff --git a/Documentation/technical/packfile-uri.txt b/Documentation/technical/packfile-uri.txt\nindex f7eabc6c76..1eb525fe76 100644\n--- a/Documentation/technical/packfile-uri.txt\n+++ b/Documentation/technical/packfile-uri.txt\n@@ -35,13 +35,14 @@ include some sort of non-trivial implementation in the Minimum Viable Product,\n at least so that we can test the client.\n \n This is the implementation: a feature, marked experimental, that allows the\n-server to be configured by one or more `uploadpack.blobPackfileUri=<sha1>\n-<uri>` entries. Whenever the list of objects to be sent is assembled, all such\n-blobs are excluded, replaced with URIs. As noted in \"Future work\" below, the\n-server can evolve in the future to support excluding other objects (or other\n-implementations of servers could be made that support excluding other objects)\n-without needing a protocol change, so clients should not expect that packfiles\n-downloaded in this way only contain single blobs.\n+server to be configured by one or more `uploadpack.blobPackfileUri=\n+<object-hash> <pack-hash> <uri>` entries. Whenever the list of objects to be\n+sent is assembled, all such blobs are excluded, replaced with URIs. As noted\n+in \"Future work\" below, the server can evolve in the future to support\n+excluding other objects (or other implementations of servers could be made\n+that support excluding other objects) without needing a protocol change, so\n+clients should not expect that packfiles downloaded in this way only contain\n+single blobs.\n \n Client design\n -------------\n-- \n2.31.1.443.g1f2fb5c85f.dirty\n\n"},{"id":"424201","messageId":"xmqqpmxxknaa.fsf@gitster.g","threadId":"55631","inReplyTo":"20210511064554.59924-1-dyroneteng@gmail.com","subject":"Re: [PATCH v2] packfile-uri.txt: fix blobPackfileUri description","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-05-11T20:50:37Z","receivedAt":"2021-05-11T20:50:42Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Teng Long <dyroneteng@gmail.com> writes:\n\n> Fix the 'uploadpack.blobPackfileUri' description in packfile-uri.txt\n> and the correct format also can be seen in t5702.\n>\n> Jonathan Tan <jonathantanmy@google.com> writes:\n>\n>>As for the commit message, limit the title to 50 characters or fewer if\n>>possible. Maybe something like \"packfile-uri.txt: fix blobPackfileUri\n>>description\" or something like that.\n>\n> Thanks for mention this, \"packfile-uri.txt: fix blobPackfileUri\n> description\" is good and meets the \"50 characters\" requirement. So the\n> title is modified. \n>\n>>Also in the commit message, maybe mention that the correct format can be\n>>seen in t5702.\n>\n> Because I am implementing another patch[1] about supporting the commit\n> object in packfile-uri, I noticed the `configure_exclusion` function in\n> t5702, which is now mentioned in the commit message.\n>\n> [1]https://public-inbox.org/git/20210507021140.31372-1-dyroneteng@gmail.com\n>\n> Signed-off-by: Teng Long <dyroneteng@gmail.com>\n> ---\n\nIt seems that the above needs a bit more polishing?\n\nI am not sure if moving the sign-off higher and inserting a\nthree-dash line before \"Jonathan Tan writes\" would be sufficient,\nbut with everything under that quoted material does not seem to\nbelong to a proposed commit log message proper.\n\nThanks.\n\n>  Documentation/technical/packfile-uri.txt | 15 ++++++++-------\n>  1 file changed, 8 insertions(+), 7 deletions(-)\n>\n> diff --git a/Documentation/technical/packfile-uri.txt b/Documentation/technical/packfile-uri.txt\n> index f7eabc6c76..1eb525fe76 100644\n> --- a/Documentation/technical/packfile-uri.txt\n> +++ b/Documentation/technical/packfile-uri.txt\n> @@ -35,13 +35,14 @@ include some sort of non-trivial implementation in the Minimum Viable Product,\n>  at least so that we can test the client.\n>  \n>  This is the implementation: a feature, marked experimental, that allows the\n> -server to be configured by one or more `uploadpack.blobPackfileUri=<sha1>\n> -<uri>` entries. Whenever the list of objects to be sent is assembled, all such\n> -blobs are excluded, replaced with URIs. As noted in \"Future work\" below, the\n> -server can evolve in the future to support excluding other objects (or other\n> -implementations of servers could be made that support excluding other objects)\n> -without needing a protocol change, so clients should not expect that packfiles\n> -downloaded in this way only contain single blobs.\n> +server to be configured by one or more `uploadpack.blobPackfileUri=\n> +<object-hash> <pack-hash> <uri>` entries. Whenever the list of objects to be\n> +sent is assembled, all such blobs are excluded, replaced with URIs. As noted\n> +in \"Future work\" below, the server can evolve in the future to support\n> +excluding other objects (or other implementations of servers could be made\n> +that support excluding other objects) without needing a protocol change, so\n> +clients should not expect that packfiles downloaded in this way only contain\n> +single blobs.\n>  \n>  Client design\n>  -------------\n"},{"id":"424341","messageId":"CADMgQSQfvacwfnhz=taR5904AJp=CWgiq50+5F0A=hN4jGo9pg@mail.gmail.com","threadId":"55631","inReplyTo":"xmqqpmxxknaa.fsf@gitster.g","subject":"Re: [PATCH v2] packfile-uri.txt: fix blobPackfileUri description","fromName":"Long Teng","fromEmail":"dyroneteng@gmail.com","sentAt":"2021-05-12T14:10:29Z","receivedAt":"2021-05-12T14:10:44Z","isPatch":true,"sender":{"key":"dyroneteng@gmail.com","avatar":"https://avatars.githubusercontent.com/u/7803958?v=4"},"body":">It seems that the above needs a bit more polishing?\n>\n>I am not sure if moving the sign-off higher and inserting a\n>three-dash line before \"Jonathan Tan writes\" would be sufficient,\n>but with everything under that quoted material does not seem to\n>belong to a proposed commit log message proper.\n\nSorry, I misunderstood.\n\nI looked at some patches in the community. If I reply to the\nreviewer’s suggestion separately and then submit a new patch, is it\nthe recommended way? (Distinguish between the ‘reply‘ and the\n'patch').\n\nAnother question is, if I need to continue to complete this patch,\nwhat do I need to do? I think it is to reply to Jonathan Tan\nseparately, and then resubmit Patch v2. Is this way correct?\n\nThanks for your reply.\n\nJunio C Hamano <gitster@pobox.com> 于2021年5月12日周三 上午4:50写道：\n\n>\n> Teng Long <dyroneteng@gmail.com> writes:\n>\n> > Fix the 'uploadpack.blobPackfileUri' description in packfile-uri.txt\n> > and the correct format also can be seen in t5702.\n> >\n> > Jonathan Tan <jonathantanmy@google.com> writes:\n> >\n> >>As for the commit message, limit the title to 50 characters or fewer if\n> >>possible. Maybe something like \"packfile-uri.txt: fix blobPackfileUri\n> >>description\" or something like that.\n> >\n> > Thanks for mention this, \"packfile-uri.txt: fix blobPackfileUri\n> > description\" is good and meets the \"50 characters\" requirement. So the\n> > title is modified.\n> >\n> >>Also in the commit message, maybe mention that the correct format can be\n> >>seen in t5702.\n> >\n> > Because I am implementing another patch[1] about supporting the commit\n> > object in packfile-uri, I noticed the `configure_exclusion` function in\n> > t5702, which is now mentioned in the commit message.\n> >\n> > [1]https://public-inbox.org/git/20210507021140.31372-1-dyroneteng@gmail.com\n> >\n> > Signed-off-by: Teng Long <dyroneteng@gmail.com>\n> > ---\n>\n> It seems that the above needs a bit more polishing?\n>\n> I am not sure if moving the sign-off higher and inserting a\n> three-dash line before \"Jonathan Tan writes\" would be sufficient,\n> but with everything under that quoted material does not seem to\n> belong to a proposed commit log message proper.\n>\n> Thanks.\n>\n> >  Documentation/technical/packfile-uri.txt | 15 ++++++++-------\n> >  1 file changed, 8 insertions(+), 7 deletions(-)\n> >\n> > diff --git a/Documentation/technical/packfile-uri.txt b/Documentation/technical/packfile-uri.txt\n> > index f7eabc6c76..1eb525fe76 100644\n> > --- a/Documentation/technical/packfile-uri.txt\n> > +++ b/Documentation/technical/packfile-uri.txt\n> > @@ -35,13 +35,14 @@ include some sort of non-trivial implementation in the Minimum Viable Product,\n> >  at least so that we can test the client.\n> >\n> >  This is the implementation: a feature, marked experimental, that allows the\n> > -server to be configured by one or more `uploadpack.blobPackfileUri=<sha1>\n> > -<uri>` entries. Whenever the list of objects to be sent is assembled, all such\n> > -blobs are excluded, replaced with URIs. As noted in \"Future work\" below, the\n> > -server can evolve in the future to support excluding other objects (or other\n> > -implementations of servers could be made that support excluding other objects)\n> > -without needing a protocol change, so clients should not expect that packfiles\n> > -downloaded in this way only contain single blobs.\n> > +server to be configured by one or more `uploadpack.blobPackfileUri=\n> > +<object-hash> <pack-hash> <uri>` entries. Whenever the list of objects to be\n> > +sent is assembled, all such blobs are excluded, replaced with URIs. As noted\n> > +in \"Future work\" below, the server can evolve in the future to support\n> > +excluding other objects (or other implementations of servers could be made\n> > +that support excluding other objects) without needing a protocol change, so\n> > +clients should not expect that packfiles downloaded in this way only contain\n> > +single blobs.\n> >\n> >  Client design\n> >  -------------\n"},{"id":"424400","messageId":"xmqq7dk3edfh.fsf@gitster.g","threadId":"55631","inReplyTo":"CADMgQSQfvacwfnhz=taR5904AJp=CWgiq50+5F0A=hN4jGo9pg@mail.gmail.com","subject":"Re: [PATCH v2] packfile-uri.txt: fix blobPackfileUri description","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-05-12T23:32:18Z","receivedAt":"2021-05-12T23:52:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Long Teng <dyroneteng@gmail.com> writes:\n\n>>It seems that the above needs a bit more polishing?\n>>\n>>I am not sure if moving the sign-off higher and inserting a\n>>three-dash line before \"Jonathan Tan writes\" would be sufficient,\n>>but with everything under that quoted material does not seem to\n>>belong to a proposed commit log message proper.\n>\n> Sorry, I misunderstood.\n>\n> I looked at some patches in the community. If I reply to the\n> reviewer’s suggestion separately and then submit a new patch, is it\n> the recommended way? (Distinguish between the ‘reply‘ and the\n> 'patch').\n\nYes.  Some people seem to omit the final response to reviewer\nsuggestions on the previous round and just send a revised patch, but\nit is much nicer to cleanly conclude the review cycle for the\nprevious round with a separate response (it could just be \"yes,\nyou're right---I'll incorporate your suggestions in the next round,\nthanks\") before starting a new cycle.\n\nAnd the \"patch\" side should be written to be understandable even by\nthose who do not have access to the review history of the previous\nround(s)---imagine how it appears in \"git log\" output to those who\ndid not read the discussion on this mailing list, and write for\nthem.\n\nThanks.\n"},{"id":"424432","messageId":"20210513071547.64367-1-dyroneteng@gmail.com","threadId":"55631","inReplyTo":"20210506073354.27833-1-dyroneteng@gmail.com","subject":"packfile-uri.txt: fix blobPackfileUri description","fromName":"Teng Long","fromEmail":"dyroneteng@gmail.com","sentAt":"2021-05-13T07:15:47Z","receivedAt":"2021-05-13T07:16:19Z","isPatch":false,"sender":{"key":"dyroneteng@gmail.com","avatar":"https://avatars.githubusercontent.com/u/7803958?v=4"},"body":"Fix the 'uploadpack.blobPackfileUri' description in packfile-uri.txt\nand the correct format also can be seen in t5702.\n\nSigned-off-by: Teng Long <dyroneteng@gmail.com>\n---\n Documentation/technical/packfile-uri.txt | 15 ++++++++-------\n 1 file changed, 8 insertions(+), 7 deletions(-)\n\ndiff --git a/Documentation/technical/packfile-uri.txt b/Documentation/technical/packfile-uri.txt\nindex f7eabc6c76..1eb525fe76 100644\n--- a/Documentation/technical/packfile-uri.txt\n+++ b/Documentation/technical/packfile-uri.txt\n@@ -35,13 +35,14 @@ include some sort of non-trivial implementation in the Minimum Viable Product,\n at least so that we can test the client.\n \n This is the implementation: a feature, marked experimental, that allows the\n-server to be configured by one or more `uploadpack.blobPackfileUri=<sha1>\n-<uri>` entries. Whenever the list of objects to be sent is assembled, all such\n-blobs are excluded, replaced with URIs. As noted in \"Future work\" below, the\n-server can evolve in the future to support excluding other objects (or other\n-implementations of servers could be made that support excluding other objects)\n-without needing a protocol change, so clients should not expect that packfiles\n-downloaded in this way only contain single blobs.\n+server to be configured by one or more `uploadpack.blobPackfileUri=\n+<object-hash> <pack-hash> <uri>` entries. Whenever the list of objects to be\n+sent is assembled, all such blobs are excluded, replaced with URIs. As noted\n+in \"Future work\" below, the server can evolve in the future to support\n+excluding other objects (or other implementations of servers could be made\n+that support excluding other objects) without needing a protocol change, so\n+clients should not expect that packfiles downloaded in this way only contain\n+single blobs.\n \n Client design\n -------------\n-- \n2.31.1.443.g2f6b6330e7.dirty\n\n"},{"id":"424515","messageId":"xmqq8s4i9v42.fsf@gitster.g","threadId":"55631","inReplyTo":"20210513071547.64367-1-dyroneteng@gmail.com","subject":"Re: packfile-uri.txt: fix blobPackfileUri description","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-05-13T21:33:49Z","receivedAt":"2021-05-13T21:33:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Teng Long <dyroneteng@gmail.com> writes:\n\n> Fix the 'uploadpack.blobPackfileUri' description in packfile-uri.txt\n> and the correct format also can be seen in t5702.\n>\n> Signed-off-by: Teng Long <dyroneteng@gmail.com>\n> ---\n>  Documentation/technical/packfile-uri.txt | 15 ++++++++-------\n>  1 file changed, 8 insertions(+), 7 deletions(-)\n\nWill queue; thanks.\n\nJonathan, how does this look?\n\n> diff --git a/Documentation/technical/packfile-uri.txt b/Documentation/technical/packfile-uri.txt\n> index f7eabc6c76..1eb525fe76 100644\n> --- a/Documentation/technical/packfile-uri.txt\n> +++ b/Documentation/technical/packfile-uri.txt\n> @@ -35,13 +35,14 @@ include some sort of non-trivial implementation in the Minimum Viable Product,\n>  at least so that we can test the client.\n>  \n>  This is the implementation: a feature, marked experimental, that allows the\n> -server to be configured by one or more `uploadpack.blobPackfileUri=<sha1>\n> -<uri>` entries. Whenever the list of objects to be sent is assembled, all such\n> -blobs are excluded, replaced with URIs. As noted in \"Future work\" below, the\n> -server can evolve in the future to support excluding other objects (or other\n> -implementations of servers could be made that support excluding other objects)\n> -without needing a protocol change, so clients should not expect that packfiles\n> -downloaded in this way only contain single blobs.\n> +server to be configured by one or more `uploadpack.blobPackfileUri=\n> +<object-hash> <pack-hash> <uri>` entries. Whenever the list of objects to be\n> +sent is assembled, all such blobs are excluded, replaced with URIs. As noted\n> +in \"Future work\" below, the server can evolve in the future to support\n> +excluding other objects (or other implementations of servers could be made\n> +that support excluding other objects) without needing a protocol change, so\n> +clients should not expect that packfiles downloaded in this way only contain\n> +single blobs.\n>  \n>  Client design\n>  -------------\n"},{"id":"424795","messageId":"xmqq8s4c6fbg.fsf@gitster.g","threadId":"55631","inReplyTo":"xmqq8s4i9v42.fsf@gitster.g","subject":"Re: packfile-uri.txt: fix blobPackfileUri description","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-05-18T00:44:35Z","receivedAt":"2021-05-18T00:44:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Teng Long <dyroneteng@gmail.com> writes:\n>\n>> Fix the 'uploadpack.blobPackfileUri' description in packfile-uri.txt\n>> and the correct format also can be seen in t5702.\n>>\n>> Signed-off-by: Teng Long <dyroneteng@gmail.com>\n>> ---\n>>  Documentation/technical/packfile-uri.txt | 15 ++++++++-------\n>>  1 file changed, 8 insertions(+), 7 deletions(-)\n>\n> Will queue; thanks.\n>\n> Jonathan, how does this look?\n\nPing?\n\n>> diff --git a/Documentation/technical/packfile-uri.txt b/Documentation/technical/packfile-uri.txt\n>> index f7eabc6c76..1eb525fe76 100644\n>> --- a/Documentation/technical/packfile-uri.txt\n>> +++ b/Documentation/technical/packfile-uri.txt\n>> @@ -35,13 +35,14 @@ include some sort of non-trivial implementation in the Minimum Viable Product,\n>>  at least so that we can test the client.\n>>  \n>>  This is the implementation: a feature, marked experimental, that allows the\n>> -server to be configured by one or more `uploadpack.blobPackfileUri=<sha1>\n>> -<uri>` entries. Whenever the list of objects to be sent is assembled, all such\n>> -blobs are excluded, replaced with URIs. As noted in \"Future work\" below, the\n>> -server can evolve in the future to support excluding other objects (or other\n>> -implementations of servers could be made that support excluding other objects)\n>> -without needing a protocol change, so clients should not expect that packfiles\n>> -downloaded in this way only contain single blobs.\n>> +server to be configured by one or more `uploadpack.blobPackfileUri=\n>> +<object-hash> <pack-hash> <uri>` entries. Whenever the list of objects to be\n>> +sent is assembled, all such blobs are excluded, replaced with URIs. As noted\n>> +in \"Future work\" below, the server can evolve in the future to support\n>> +excluding other objects (or other implementations of servers could be made\n>> +that support excluding other objects) without needing a protocol change, so\n>> +clients should not expect that packfiles downloaded in this way only contain\n>> +single blobs.\n>>  \n>>  Client design\n>>  -------------\n"},{"id":"425436","messageId":"20210524154354.268200-1-jonathantanmy@google.com","threadId":"55631","inReplyTo":"xmqq8s4c6fbg.fsf@gitster.g","subject":"Re: packfile-uri.txt: fix blobPackfileUri description","fromName":"Jonathan Tan","fromEmail":"jonathantanmy@google.com","sentAt":"2021-05-24T15:43:54Z","receivedAt":"2021-05-24T16:09:31Z","isPatch":false,"sender":{"key":"jonathantanmy@fastmail.com","avatar":null},"body":"> Junio C Hamano <gitster@pobox.com> writes:\n> \n> > Teng Long <dyroneteng@gmail.com> writes:\n> >\n> >> Fix the 'uploadpack.blobPackfileUri' description in packfile-uri.txt\n> >> and the correct format also can be seen in t5702.\n> >>\n> >> Signed-off-by: Teng Long <dyroneteng@gmail.com>\n> >> ---\n> >>  Documentation/technical/packfile-uri.txt | 15 ++++++++-------\n> >>  1 file changed, 8 insertions(+), 7 deletions(-)\n> >\n> > Will queue; thanks.\n> >\n> > Jonathan, how does this look?\n> \n> Ping?\n\nSorry, I just got back on vacation. This looks good - it's exactly the\nsame as the change I approved previously [1].\n\nTeng Long, for future reviews, the review would go faster if you\nmentioned the changes in between versions (e.g. in this case, you\nupdated the commit message following my suggestions).\n\n[1] https://lore.kernel.org/git/20210506164728.336409-1-jonathantanmy@google.com/\n"},{"id":"425473","messageId":"xmqqsg2birce.fsf@gitster.g","threadId":"55631","inReplyTo":"20210524154354.268200-1-jonathantanmy@google.com","subject":"Re: packfile-uri.txt: fix blobPackfileUri description","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-05-25T00:34:25Z","receivedAt":"2021-05-25T00:34:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Tan <jonathantanmy@google.com> writes:\n\n>> Junio C Hamano <gitster@pobox.com> writes:\n>> \n>> > Teng Long <dyroneteng@gmail.com> writes:\n>> >\n>> >> Fix the 'uploadpack.blobPackfileUri' description in packfile-uri.txt\n>> >> and the correct format also can be seen in t5702.\n>> >>\n>> >> Signed-off-by: Teng Long <dyroneteng@gmail.com>\n>> >> ---\n>> >>  Documentation/technical/packfile-uri.txt | 15 ++++++++-------\n>> >>  1 file changed, 8 insertions(+), 7 deletions(-)\n>> >\n>> > Will queue; thanks.\n>> >\n>> > Jonathan, how does this look?\n>> \n>> Ping?\n>\n> Sorry, I just got back on vacation. This looks good - it's exactly the\n> same as the change I approved previously [1].\n\nThanks.\n\n>\n> Teng Long, for future reviews, the review would go faster if you\n> mentioned the changes in between versions (e.g. in this case, you\n> updated the commit message following my suggestions).\n>\n> [1] https://lore.kernel.org/git/20210506164728.336409-1-jonathantanmy@google.com/\n"}]}